1 нояб. 2016 г., 5:33
modMonitor-2.0.0-beta. Мониторинг производительности сайтов на MODX Revolution
Сегодня мы публикуем очень важный и мощный компонент — 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: Забыл сказать, что замечания и пожелания по компоненту можно фиксировать здесь: bitbucket.org/modxclub/modmonitor/issues
В планах добавить графики и отчетные периоды.
UPD2: В версии 2.1.0 добавил вывод в статистику флаг из кеша документ получен или сгенерирован.
?
Да, этот инструмент действительно позволяет значительно сократить время поиска тонких мест
Выложил modMonitor-2.6.6
Поправлена логика сбора статистики по элементам. Теперь корректней учитывается очередность и вложенность элементов, в том числе и плагинов.
joxi.ru/5mdkp83skvoY3r
Кстати, в отладке modMonitor действительно незаменим. К примеру, сейчас для себя выяснил, что он не умеет отлавливать информацию о статических плагинах joxi.ru/LmGVQx0ueRX5Vr
Это связано с тем, что отладку он вписывает в кеш плагинов (не имея других точек вхождения по плагинам). Но статические элементы MODX не берет из кеша, а каждый раз вызывает с нуля. По этой причине код, вписанный в кеш элементов, не учитывается… Надо думать что-то новое. Как крайний вариант — вклиниваться в механизм сохранения плагинов, но эта идея мне не очень нравится.
modMonitor крутой, но все возможности только ты знаешь
Надо больше кейсов описать и документацию, видимо, написать…