Сегодня мы публикуем очень важный и мощный компонент — modMonitor. Я уже ранее про него писал, но особо не пиарил его, так как разрабатывал его больше для себя (с ним проводить техническую оптимизацию сайтов гораздо проще) и собираемые данные анализировал обычными SQL-запросами в phpMyAdmin. То есть никаких интерфейсов к нему не прилагалось и большинство пользователей просто не смогли бы им пользоваться. А вот сегодня я сел оптимизировать одного весьма серьезного подопечного и заодно добавить в админку таблички для вывода собираемой информации. В итоге получилось очень даже юзабельно :)

(здесь видно насколько губителен для сайта Wayfinder в плане производительности)))

Немного о “подопечном”: это самописная CRM-система на базе MODX, причем весьма крупная — в базе данных на сегодня более 550 000 заявок и 1 400 000 исторических записей к ним, не считая пользователей, небольшой биллинг и т.п. Взяли мы их к себе чуть больше года назад и на тот момент количество заявок было в два раза меньше. Изначально не мы их разрабатывали, достались они к нам “в наследство”, когда заказчик устал от предыдущих исполнителей и решился таки сменить их.

К слову, денег было потрачено на систему очень и очень не мало, тем не менее это как раз тот случай, когда деньги не решают, исполнителю просто не хватило опыта на реализацию такого уровня проекта, в итоге хотя информация в БД и попадала, работать с ней было почти невозможно, они даже за месяц не могли получить отчеты, так как для формирования табличных данных во фронт они брали все записи за запрошенный период и уже на уровне php пытались перебирать массивы и формировать итоговые таблицы… Такая выборка за месяц требовала порядка 300 мегабайт памяти и 30 секунд времени. Когда мы переделали, более функциональная выборка за этот период выполнялась 2 секунды, а за весь период (почти два года) — 10-15 секунд. Итоговая таблица выглядить вот так:

Уточню, что здесь каждая ячейка кликабельная, можно кликнув на нее получить выборку конкретно по этому состоянию

Так вот, несмотря на то, что многое мы там поправили, довольно много косяков низкоуровневых остались от предыдущих исполнителей и отлавливать их очень сложно. Все усложняется еще тем, что с системой только со стороны заказчика работает несколько десятков человек, плюс к этому API, посредством которого несколько партнеров отправляют заявки и запрашивают по ним статусы, а еще каждые пять минут идет забор заявок с нескольких емейлов, да еще и конечные партнеры, обрабатывающие заявки, сидят в личном кабинете. Итого в день поступает несколько сотен заявок , в течение дня больше сотни человек сидит постоянно и в рабочее время сайт обрабатывает до нескольких тысяч запросов (это еще не считая запросов на коннекторы и т.п.). В общем, когда работа закипает на полную, бывает что все 8 процессоров на сервере загружаются на 100%.

Первый раз я modMonitor задействовал на этом проекте пару недель назад, когда система просто отказывалась работать, запросы к сайту не успевали отрабатываться и вставали в очередь. Вот тогда modMonitor помог выявить проблему. Сейчас, когда я доработал интерфейсы для него и обновил компонент на сайте, я могу наглядно показать проблему: (кстати, обратите внимание в правом нижнем углу указано сколько запросов в базе сейчас содержится, это статистика за неделю :) ). В итоге проблемный элемент был найден, далее я навесил несложный плагин на запросы и в логах уже выяснил, что один партнер просто по несколько таких запросов в секунду слал на сайт, чем по сути и дидосил систему. Ну я его заблокировал и рапортовал клиенту, тот отправил привет партнеру, который в свою очередь поправил логику своей системы и начал уже слать нормально запросы раз в 10 минут. В php-логах я долго бы копался, так как сложно было бы отличить нормальные запросы от злобных, ибо пользователи постоянно онлайн и шлют много запросов.

С этим сниппетом вообще веселье оказалось:) Мало того, что они в цикле получали запрошенные элементы , так там еще и поле было не индексируемое, да еще и под хранение несколько символов тип данных был задан text. В итоге попробовал выполнить сниппет с запросом 50-ти заявок, действительно выполняется 30 секунд 30 секунд на 50 записей, Карл!

Поправил тип поля и добавил индекс. Те же 50 заявок 0.2 сек

Переписал получение объектов в цикле на один xPDO-запрос, вообще за сотые доли стал выполнять

Есть разница?

modMonitor помог выявить и другое проблемное место

Правда только сегодня я в систему добавил логирование и айдишника пользователя, от имени которого запрос выполнялся, что позволит отлавливать более индивидуальные моменты. Дело в том, что эта страница отрабатывает разную логику в зависимости от роли пользователя. Сегодня вот будет статистика с учетом пользователей и тогда уже можно будет потестировать от имени проблемных пользователей. К слову, напомню, что компонент switchUser позволяет легко авторизоваться от имени любого пользователя.

Напоследок чуть поподробней о том, что же такое modMonitor. Суть компонента в том, что он на уровне плагина при инициализации MODX-а расширяет MODX-парсер, отслеживая вызовы MODX-элементов (чанков и сниппетов), собирая информацию о количестве запросов к БД и времени выполнения. В базе данных он хранит общую информацию по каждому запросу к странице (один запрос — одна запись в БД со статистикой времени выполнения, количество запросов к БД, ip, пользователь и т.п.) и отдельно по каждому вызванному элементу (одна запись — один элемент (чанк или сниппет)).

Сейчас в админке у него два интерфейса.

Первый — список всех вызываемых элементов в обратном хронологическом порядке

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

Второй — список запросов с возможностью в подгриде видеть информацию по вызванным элементам, так же с группировкой.

Кстати, для тех, кто поддерживает не один сайт, есть очень приятный момент: изначально при разработке компонента ставилась важная задача: умение собирать статистику с нескольких сайтов. Для этого в настройках компонента можно указать логин и пароль БД, куда сливать статистику. Таким образом компонент можно установить на нескольких сайтах, а статистику потом просматривать в единой панели.

В настоящий момент еще есть мелкие неточности в детальном логировании статистики выполнения элементов, но общее время считается довольно корректно, а полученная информация вполне наглядна. На ближайшее будущее есть ряд планов по улучшению компонента (особенно это касается всевозможных фильтров в интерфейсах).

В общем, как разработчик, специализирующийся на технической оптимизации MODX-сайтов, могу сказать, что modMonitor — вещь просто незаменимая :) Компонент уже доступен для скачивания в нашем репозитории. Стоимость доступа к репозиторию, считаете, высока? Посмотрите наши цены на техническую оптимизацию сайтов. Поверьте, эти цены не просто так указаны. А с modMonitor можно попытаться самостоятельно выявить проблемы на сайте. А с учетом того, что подписку можно оплатить раз, а установить компонент на сколько угодно сайтов, так вообще за бесценок получается. Плюс ко всему не забываем, что у нас по прежнему работает принцип pay-back, то есть часть оплаты уходит на ваш личный счет, который можно использовать на нашу поддержку.

P.S. Пусть еще кто-то скажет, что на MODX нельзя крупные проекты делать :)

UPD: Забыл сказать, что замечания и пожелания по компоненту можно фиксировать здесь: https://bitbucket.org/modxclub/modmonitor/issues В планах добавить графики и отчетные периоды.

UPD2: В версии 2.1.0 добавил вывод в статистику флаг из кеша документ получен или сгенерирован.