Как стать автором
Обновить

Modx и «ограничение» в 5000 документов

Время на прочтение 6 мин
Количество просмотров 11K

Вступление


Modx — замечательный фреймворк, но на ресурсах и в разделах, посвященных modx, можно читать посты о неком ограничении фрейморка в 5000 документов, да и заказчики бывает спрашивают будет ли сайт работать, если страниц будет больше 5 тысяч.
Вы уже наверное догадались, речь пойдёт о modx evolution (версии 1.0.5).

Когда есть задача сделать сайт больше визитки, возникает вопрос: насколько много страниц может обслуживать cmf/cms и насколько быстро?

Modx знаменит своей гибкостью, и практически для любой задачи можно придумать несколько вариантов решений, но самое узкое место — кэширование, конкретно нас интересует файл assets/cache/siteCache.idx.php который содержит абсолютно всё, что можно закэшировать (кроме самих страниц, для которых есть свой кэш-файл вида assets/cache/docid_<ID страницы>.pageCache.php).
Обойти небольшие неудобства, которые могут возникнуть (если делать портал и хранить всё как документы modx) в большого сайта при текущей концепции кэширования modx можно несколькими способами, о которых немного ниже.

Что не так с кэшированием


Всё с ним так, но есть один момент — когда кэш очищается, главный кэш-файл siteCache.idx.php должен пересобратся заново.

Обновление кэша провоцируют такие события, как любые изменения тв-параметра(ов), чанков, сниппетов, шаблонов, изменения в документах (добавили новый ресурс или сняли с публикации любой другой — нужно «освежить» массив идентификаторов документов), в результате, если в наличии сайт-каталог с несколькими сотнями документов, в большей половины из которых с десяток тв-параметров — размер siteCache.idx.php может быть несколько МБ, и увеличиваться, при этом для формирования нового кэш-файла нужно выполнить с десяток sql-запросов, если не больше, этот файл будет успешно перезаписываться до тех пор, пока будет хватать выделенной памяти (memory_limit) как на операцию формирования главного кэш-файла, так и на другие запросы по формированию текущей страницы (на которой в данный момент находимся), в противном случае получим ошибку: Fatal error: Allowed memory size of ... bytes exhausted (tried to allocate ... bytes) in ..assets/cache/siteCache.idx.php on line ....

Типичные ошибки в больших сайтах


Под большим сайтом будем представлять ресурс в несколько тысяч документов, количество которых постоянно увеличивается.

При неправильном проектировании сайта основная нагрузка ляжет на файловую систему, а конкретно — на запись siteCache.idx.php, рассмотрим один из возможных вариантов.

Например, блог на modx

Допустим есть блог на modx, контент которого «генерируют» пользователи, каждый размещает свои статьи, которые пишутся в БД как документ modx и отображаются в дереве документов, что есть вполне логично и даже удобно, так как не нужно делать дополнительную работу: отдельную таблицу, контролёры для управления данными от имени пользователя и админа (это несколько часов потрудится, в зависимости от сложности), а инструменты для редактирования сайта админом/менеджером из fron-end’а есть «из коробки» вполне удобные.

При добавлении нового документа в modx — необходимо очистить весь кэш, так при частоте 2-3 документа в минуту сайт может притормаживать, с ростом количества документов тормоза увеличиваются, со временем сайту не хватит выделяемой памяти и сервер выдаст ошибку которая начинается: «Allow memory size of...».
Можно увеличить размер выделяемой памяти, но бесконечно увеличивать нельзя (не будем сейчас говорить почему), придётся, рано или поздно, пересмотреть концепцию нашего блога и большую часть работы переписать.

Тестирование modx


Чтобы не быть голословным, сделал небольшой тест в домашних условиях, смоделировав пример «блог на modx».

Цель тестирования

Проверить лично, что модх может работать более чем с 5.000 документами, установить, при каких условиях modx может перестать работать.

Инструменты

Ноут: CPU Core i3 2.13Ghz, RAM 8Gb DDR3, HDD 500gb 5400об.мин.
Софт: Windows 7 x64, Apache 2.2.12, php 5.3.0, mysql 5.1.36
Настройки сервера: обычный веб-сервер xampp, обычные настройки, значение memory_limit установил в 64Mb.

План работы

  1. установить modx evolution 1.0.5
  2. создать: 30 копий шаблонов, 50 чанков, 30 сниппетов, 100 тв-параметров, 5.000 документов
  3. написать скрипт, который частично сделает пункт 2, выполним пункт 2.
  4. если админка не работает — делаем пункт 6, если работает — делаем пункт 5
  5. увеличивает количество документов ещё на 5.000, смотрим пункту 4
  6. увеличиваем memory_limit до 128 мб, если ошибок нет — смотрим пункт 5.
  7. если дошли к этому пункту, значит получили ошибку «Allow memory size of...», делаем выводы.


Ход работы

Установили (начало и финиш) фреймворк, вместе с всеми чанками и сниппетами, которые включены по умолчанию.

На стадии тестирования не существенно, какие именно данные будут содержать шаблоны, чанки, сниппеты, тв-параметры, документы. Будем постоянно копировать один и тот-же элемент.
Для операций копирования ресурсов был написан небольшой скрипт:
  1. исходник
  2. скопировать в assets/snippets/test/test.php
  3. запускать index-ajax.php?q=assets/snippets/test/test.php

В админке сделал копию первого документа (id = 1), в качестве дочернего для скопированного (id=2) установил документ id=1, и запретил отображать документ в меню (когда будет много документов — необязательно видеть всех их на сайте), скрипт будет копировать созданный документ (id=2) и все клоны будут в качестве родительского иметь первый документо (id=1).

Копирование ресурсов



Начальный размер siteCache.idx.php — 161Кб.

Шаблоны, донором будет «MODxHost» — примерно столько же места занимают любые другие шаблоны в большинстве проектов, сделал 30 копий, также скопировал 100 тв-параметров, 50 чанков (донором выступил WebLoginSideBar), 30 сниппетов (донор — AjaxSearch, достаточно много кода содержит, то что нам нужно).

После этих нехитрых операций размер siteCache.idx.php увеличился до 1.370Мб, сайт и админка работает, создаём много документов (напомню, скрипт дублирует документ с id=2, также для id=2 вставим немного содержимого, статью например откуда нибудь, я скопировал отсюда кусок).

Результаты тестирования в таблице


image

Попытка создать ещё 5к документов при memory_limit=128Mb и наличии 60к документов была безуспешной.

При тестировании, в админке перестали загружаться документы в дереве документов, хотя админка работала, это из-за того, что копировал все документы к одному «родителю» (id=1), и на выборку и вывод нужных дочерних документов не хватало выделенной памяти.

При создании кэш-файла siteCache.idx.php стоит учитывать с какой именно страницы создаётся главный кэш-файл, так как сниппеты и плагины, которые используются на конкретной странице, тоже расходуют выделяемую для РНР память, потому максимальное количество документов ещё зависит от того, насколько грамотно написаны сниппеты и как построены запросы.

Тест окончен, при memory_limit 64Мб и 128Мб примерно 15к и 60к соответственно может обслуживаться в modx, это явно больше заявленного ограничения в 5к документов, конечно это не есть эталон, но есть показателем того, что modx, в принципе, может работать с большим количеством документов.

Организация структуру сайта


Чтобы избежать проблемы нехватки выделяемой памяти, могу посоветовать принципы, которых следует придерживаться при создании сайта или портала на modx:
  • не писать очень много дочерних документов для одного родителя, стараться логически распределить документы по группам;
  • динамический контент для огромных каталогов следует организовать в отдельной таблице, написать для неё нужные сниппеты, если нужно ЧПУ для данных в таблицах — можно написать плагин или сниппет, и повесить на страницу 404, которая будет выдавать контент, если данные есть в нашей таблице;
  • избегать запросов «SELECT * FROM <TABLE>», выбирать надо только то, что нам нужно, не более, сложные запросы разбивать на несколько простых;
  • не злоупотреблять, например, вызовами Ditto, в практике встречал с десяток некэшированных вызовов Ditto на одной странице, что жутко тормозило сайт, для конкретной задачи лучше писать конкретный сниппет, который не делает ничего лишнего.


Конечно, если предполагаемое количество страниц на сайте в несколько тысяч — перед разработчиком возникают уже другие задачи, и если modx и используется, то только для статического контента и как мост для данных в других таблицах.

Заключение


Как видим, modx может работать с большим количеством документов, evolution можно без проблем использовать для создания больших порталов и интернет-магазинов, правда подход должен быть с умом. Modx — всего лишь инструмент, от того, как этим инструментов будет пользоваться разработчик, зависит качество созданного ресурса.
В статье не упомянут modx revolution, как лучше делать сниппеты (отдельным файлом, или код хранить в БД) и многое-многое другое, про modx написать можно очень много.

С удовольствием почитаю замечания или критику по статьи и коду.
Специально, для Хабра.
Теги:
Хабы:
+25
Комментарии 19
Комментарии Комментарии 19

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн