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

Вступление


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 написать можно очень много.

С удовольствием почитаю замечания или критику по статьи и коду.
Специально, для Хабра.
Поделиться публикацией

Похожие публикации

Комментарии 19

    0
    Такое количество страниц может свидетельствовать еще и достаточном трафике на сайт. И если сайт будет настолько здоровым, то может стоит задуматься о легковесных фреймворках типа Yii, CodeIgniter, Kohana?
      +2
      Цель написания — развеять миф о том, что modx, не справится с 5к документами.

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

      Если делать прямыми руками — скорость загрузки страниц сайта не будет превышать в среднем 0,5 секунд.

      Для настолько здоровых сайтов будет применяться совсем другая концепция, или же modx revolution.
        –1
        Если 0,5 секунд отрабатывает код то это уже долго!
        Когда я писал инет магазин, то любая страница отрабатывает за 0.06 — 0.1 секунды.

        Я маньяк по поводу скорости и CMS не люблю и ничего на них не пишут.

        Но постоянно приходится с ними работать и ModX из CMS мне самое больше нравится.
          0
          0.5с — на генерацию страницы (рнр+mysql), на локальном сервере, вполне нормальный результат (это без кэширования, из БД), с кэшированием естественно меньше, но 0.5с на продакшине обычно уменьшается раза в 2-3, а ещё можно использовать акселератор и другие штуки.

          Вот результат загрузки страницы блога, который сейчас разрабатывается: MySQL: 0,0322 s, 16 request(s), PHP: 0,0677 s, total: 0,0999 s, document retrieved from database (расположен на обычном хостинге, ссылку написать не могу по некоторым соображениям)
      0
      хотел бы про революшн увидеть подобный обзор
        +1
        К сожалению, плохо разбираюсь в революшн, нет достаточно свободного времени для изучения её.

        И не очень удобно админкой революшн пользоваться, особенно с ноута 15.6", еволюшн более удобный для контент-менеджеров, которые бывает пользуются относительно старыми браузерами, а админы некоторых компаний из личных соображений отказываются использовать более нового ПО, сайт, админкой которого не комфортно пользоваться менеджерам, не очень успехом пользоваться будет.

        Пока не будет весомых оснований делать проекты на революшн (не потому что новый/модный фреймворк) — именно еволюшн стоит использовать, хотя как только аудитория начнет меняться в пользу революшн, переход на последний будет не медлительный, отсюда и опыт и вдохновение делиться опытом.
          +1
          У Рево с кэшированием получше. Недавно тестировал (на скорую руку). При 30 000 ресурсов (документов) размер индексного файла кэша — меньше мегабайта. Но там есть другие моменты, которые влияют на производительность. Какие я пока не вникал.
          0
          Пожалуй, не один я буду благодарен, если кто-нибудь из специалистов по MODx напишет хорошую статью про организацию регистрации/авторизации пользователей в MODx Revolution. Толковых материалов по этой теме мало, особенно под Revo. Спасибо!
            +2
            А есть какие-то сложности? rtfm.modx.com/display/ADDON/Login

            Комплект для всех случаев жизни. Ставится из репозитория, поддерживают его сами разработчики Revo.
            Примеры есть, все параметры есть, что вы еще хотите?

            Вот пример формы регистрации rtfm.modx.com/display/ADDON/Register.Example+Form+1

            Если вдруг, вам чего то не хватает в этих сниппетах — освайвайте Хуки. rtfm.modx.com/display/ADDON/Login.Using+Pre+and+Post+Hooks — это как бы миниплагинчики до и после отработки сниппета регистрации.
            0
            Я тестировал modx на 5000-10000+ документов (озоновские каталоги, с кучей tv). 5000 держит нормально, но около 10к админка грузится по 40 секунд на недорогом vps, т.к. загружает все дерево документов. А фронтенд выдержит и 50к документов, и больше, просто в админку зайти будет непросто (надо будет отключить дерево документов)…
              0
              Интересно смотреть как организован сайт.
                0
                Сайта как такового уже нет, был написан скрипт на пхп который парсит каталог со всей иерархией, и наполняет админку. В конце-концов отказался от modx как платформы для большого кол-ва документов (100k+).
                  0
                  Доки в отдельной базе решили бы эту проблему практически полностью
              +1
              1. Всё это уже было.
              2. Расход памяти зависит также от посещаемости сайта. Вы протестировали работу только для одного посетителя. Умножайте эти результаты на число посетителей и получится не очень красивая картина.
                0
                > 1. Всё это уже было.
                Не посещал тот сайт, мельком видел, но не читал, спасибо, буду в курсе.
                > 2. Расход памяти зависит также от посещаемости сайта…
                Верно, параметр не рассматривался.
                +2
                Тема избитая уже многократно. Статья в стиле «Если очень хочется — на MODX можно фсе!!!»

                Спасибо, мы в курсе. Потому на нем и работаем.

                И кстати, довольно давно вышел Evolution 1.0.5, а версии старее лучше не использовать: forums.modx.com/thread/268/modx-evo-1-0-4-and-prior-sql-injection-and-directory-traversal-vulnerabities#dis-post-1674
                  0
                  Тема избитая, согласен, но этот вопрос, как не странно, до сих пор задают — постарался очередной раз чуть прояснить.

                  Кто в админке смотрит «Сайт — Главная — Уведомления безопасности» — видел тревожное сообщение.
                  Конечно 1.0.4 лучше больше не использовать. (В данном случае эта версия завалялась в недрах локального сервера, на ней и тестил)
                    0
                    Интересный подход.
                    0
                    Ошибся, посмотрел скрин админки — оказывается не 1.0.4, а 1.0.5, залип что-то на 1.0.4 =)
                    Поправил, спасибо.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.