Внезапно, оказалось, что в магазине, в котором предполагалось 20 000+ товаров, на самом деле 150 000+ товаров… Ну чтож, давно хотел сделать магазин покрупнее :-) Очень краткая предыстория: перенос существующего интернет-магазина с самописного движка на MODX Revolution. Проблема №1: документы создаю через процессор resource/create, а обновляю через resource/update. Сама проблема заключается в малой скорости выполнения (из-за большого кеша карты ресурсов). Здесь помогает cacheOptimizer. Устанавливаем его и отключаем полностью кеширование карты кесурсов. Производительность на процессорах сразу поднимается в 3+ раза. Вторая проблема тут же: в источнике очень много документов с повторяющимися названиями, а задача стоит такая, что ЧПУ-алиасы надо сгенерировать. И вот здесь почти каждую секунду цикл выполнения процессоров обрывается из-за дубляжа алиасов. Пошел на небольшую хитрость — создал расширяющий resource/create, resource/update процессор, и перегрузил проверку алиаса. Если если дубликат алиаса, я добавляю к алиасу случайное число, и вызываю родительскую функцию. Там опять выполняется проверка, и если дубляжа нет — едем дальше, а если есть, то тогда уже окончательно останавливаем выполнение ошибкой. Вот код такого update-процессора. Проблема №2: лимит на выполнение скриптов 30 секунд. Я веду работу на modxcloud.com, а там лимит на выполнение скриптов — 30 секунд. За это время MODX успевает прогрузить порядка 300-400 документов. А надо прогрузить более 150 000 документов (скрипт выполняю через Console). Так вот, здесь я использую маленькую хитрость: дело в том, что за 30 секунд — это nginx отбивает, но php-то живет своей жизнью. Так что я ставлю лимит записей гораздо больше (к примеру 5000), а в скрипте пишу это: Теперь даже если nginx отбивает через 30 секунд, сам php-скрипт продолжает выполняться. Каковы лимиты самого php я не знаю (на некоторых хостингах часто обрывают скрипты не только по времени, но и по «очкам нагрузки»), но во всяком случае 5000 записей за раз он прогружает. А выполняется скрипт или нет, я смотрю по остаткам не отработанных записей через phpMyAdmin. Конечно, особого выигрыша во времени в таком случае нет, но зато пока импортируются 5000 документов, можно чем-то параллельно позаниматься. Проблема №3: большой кеш контекста. При частичном отключении карты ресурсов (фишка Ревы 2.2.7) кеш-файл весит почти 3,5 метра, а при заходе на сайт потребляется от 47Mb и больше. А если включить полное кеширование карты ресурсов, то объем кеш-файла почти 15 метров (и кеш создается секунд 8), а памяти во фронте кушается… А хз сколько кушается. На modxcloud.com все разваливается при заходе во фронт (просто белый экран без всяких сообщений об ошибках, как я ни старался их включить), а в админке дерево ресурсов вообще ответа от сервера нет. В общем, карту ресурсов отключаем полностью. Проблема №4: долгие запросы к БД. У нас получается 150 000+ в таблице документов, 150 000+ в таблице товаров (потом еще будет наверняка не одна сотня тысяч записей в таблице TV-параметров). Так вот, индексы конечно настроены, и при простых джоинах запросы выполняются довольно быстро. Но как только начинается поиск по условиям, вот тут запросы начинают выполняться и пол-секунды, и больше. При чем одно дело, когда мы получаем какое-то ограниченное количество записей (эти запросы выполняются довольно быстро, так как СУБД получает запрашиваемое кол-во записей, и как только лимит получен, выборка прекращается). Но вот когда выполняется подсчет всех результатов, попадающих под условия запроса (а это нам надо знать для постраничности), вот тогда СУБД-шке надо подсчитать вообще все строки, то есть сделать полную выборку из указанных таблиц. Вот тогда время выполнения запроса запросто выходит за 1 секунду. И вот даже при использовании list-процессоров из shopModx выборка 10-ти документов (с подсчетом общего числа найденных записей) занимает 2 и более секунды. Решение довольно не сложно в данном случае. Мы просто пишем общий запрос и делаем выборку всех записей из связанных таблиц без учета поиска. У нас получается одна такая большая таблица (content и т.п. нам не нужны, так как поиск мы по ним не делаем (если не делаем), нам эта таблица нужна только для поиска ID-шников тех документов, которые удовлетворяют условиям поиска, а по этим id-шникам мы уже получим конечные результаты из основных таблиц, так как чисто по id-шникам поиск выполняется достаточно быстро). А вот list-процессор из shopModx-а пришлось серьезно оттюнинговать. Во-первых, основным объектом для запросов установил объект этой кеш-таблицы. Во-вторых, заменил стандарный $modx->getCount() на вот такую хитрую конструкцию (особенно обратите внимание на$this->modx->getValue()): Работает она гораздо быстрее стандартного $modx->getCount(), так как тот выполняет подсчет уникальных id-шников, а не просто count(*). Вот так там запрос строится: Разница в скорости подсчета в несколько раз. UPD: в дальнейшем пришлось все-таки запрос переделать на count(distinct model_id), так как в кеш-таблице PK был category_id, model_id, product_id, и при выборке уникальных записей именно для model_id, простого подсчета общего числа строк было не достаточно. В кеш-таблице удалил отдельные индексы для deleted, hidemenu, published и создал единый индекс для этих трех колонок. По наблюдениям при поиске по одной из этих трех колонок с отдельными индексами разницы в скорости не замечено, а вот как только хотя бы по двум колонкам ищешь, сразу скорость падает в раза в два. В итоге, после всех этих манипуляций, я добился полного выполнения процессора на выборку 10-ти документов с полным подсчетом общего количества и т.п. менее чем за 0.09-0.2 сек. Итоговый процессор после тюнинга стал выглядеть так: gist.github.com/Fi1osof/d5a4dd427ee31b568e01/365a4ee20661b87c43b369e31683f9cad1c40635 Но все же этот результат не очень устраивал, так как конечная страница рендерилась 0,5-0,7 секунд, а это все-таки долго. В итоге я решил перевести MODX на кеш-провайдер APC, а результаты выборки из базы данных кешировать, чтобы не дергать каждый раз базу данных, тем более, что основную нагрузку создавал именно подсчет общего числа записей, удовлетворяющих условиям поиска, так что хорошего результата достаточно было просто кешировать этот результат, а конечную выборку со всеми сортировками и т.п. можно было бы уже и не кешировать, так как это только несколько записей. С формированием ключа проблем не возникло. На общее количество записей влияет только условие WHERE. Sort и т.п. вообще не учитываются. В итоге я написал вот так: То есть я беру условие WHERE прям из самого объекта запроса (и таким образом избавляюсь от необходимости вклиниваться во все точки формирования условий), и формирую кеш-ключ. А далее если результат есть в кеше, то возвращаю его, а если нет, то получаю результат от базы данных и сохраняю его в кеш. С такой маленькой хитростью время на выполнение процессора сократилось до 0,02-0,05 сек, то есть сразу в несколько раз, а рендер страницы сократился до 0,3 — 0,5 сек (это кешируемая страница с некешируемым постраничным выводом каталога по 32 товара на страницу). Уже больше похоже на правду. Измененный процессор: gist.github.com/Fi1osof/d5a4dd427ee31b568e01/53da648ce470ea05db2f3bdffe0795b2e6a9bec0 Но я решил на этом не останавливаться, а еще включить кеширование уже конечного массива данных. В итоге, переопределил основную функцию process: В этой функции я специально не стал сразу возвращать конечный результат, а прогоняю через$this->outputArray(), так как в той функции вызывается getPage. А если я этого не буду делать, то постраничность у нас просто пропадет (вывод [[+page.nav]]). Измененный процессор: gist.github.com/Fi1osof/d5a4dd427ee31b568e01/a0e4a39ddf9e90117204cfad591aed6ad7e98df7 И вот здесь еще один сюрприз меня ждал — getPage. Оказывается, он ппц какой прожорливый. Сравним скорость выполнения процессора без getPage — 0,036 сек., и с getPage — 0,15-0,17 сек. Сразу скорость выполнения падает почти в 5 раз. А ведь это основной процессор на выборку данных каталога. А сравним рендер страницы. Без getPage (страница из кеша, но процессор вызывается) — 0.1152-0.2 сек. А с getPage? 0.28-0.36 сек. В итоге один getPage выжирает в 2-3 раза больше, чем требуется всей странице! Ппц… Короче, getPage — следующий на замену. Надо будет тоже переписать. P.S. Ссылка на магазин будет после того, как я закончу хотя бы основную часть. Продолжение следует… P.S.S. если кому понадобится, ревизия изменения процессора: gist.github.com/Fi1osof/d5a4dd427ee31b568e01/revisions