Оптимизация ЛС, часть 2

А пока товарищи в соседнем топике спорят, я провел небольшие замеры и предлагаю взглянуть на некоторые варианты оптимизации.

Продолжаем эксперименты над движком.

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

В прошлом топике, где я опубликовал полный список стандартных хуков для ЛС 1.0.1, я обратил внимание на хуки, которые начинаются с префикса module_ — хуки, которые постоянно создаются динамически и вызываются парами до и после вызовов методом модулей. Как и было написано в предыдущем топике — хуки вызываются 486 раз, причем само их количество на «чистой» ЛС значится в 161 штуку.

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

  1. Ставим чистую стандартную ЛС и отключаем некоторые параметры (модуль ЛС, кеш и т.п.), которые могут повлиять на значения в большей степени нежели нагрузка на процессор фоновыми приложениями.
  2. Выключаем все плагины.
  3. В файл шаблона statistics_performance.tpl в конец добавим строки:
    
    <br />
    memory peak usage: {round(memory_get_peak_usage()/1024,1)} KB
    <br />
    memory usage: {round(memory_get_usage()/1024,1)} KB
        

для вывода количества использованной памяти движком.

Базовые приготовления закончены.

Методика проверки

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

1. Стандартная поставка ЛС
Замеряем параметры ЛС из «коробки».

Время инициализации модулей ЛС: 0.1436 сек.
Полное время выполнения: 0.4542 сек.
Пиковое потребление памяти: 10337 Кб
Использование памяти: 10184.8 Кб

2. Отключение вызова хуков в ядре ЛС

Производим редактированием ядра:
Открываем Engine.class.php и закомментируем следующие строки:
#318

$this->Hook_Run($sHookPrefix.'before');

#323

$this->Hook_Run($sHookPrefix.'after');

#539

$aResultHook=$this->_CallModule('Hook_Run',array('module_'.$sModuleName.'_'.strtolower($sMethod).'_before',&$aArgs));

#555

$this->Hook_Run('module_'.$sModuleName.'_'.strtolower($sMethod).'_after',array('result'=>&$result,'params'=>$aArgs));


Время инициализации модулей ЛС: 0.1368 сек.
Полное время выполнения: 0.4038 сек.
Пиковое потребление памяти: 10333.4 Кб
Использование памяти: 10181.2 Кб

Итоги тестирования
На чистом движке данная оптимизация почти не сказывается, т.к. с применением данной технологии:

  • Время инициализации модулей уменьшилось на 0,0068 сек. (4,73%),
  • Полное время выполнения уменьшилось на 0,0504 сек (11%).
  • Потребление памяти уменьшилось на 3,6 кб

Но вполне можно сказать что данный подход увеличит производительность движка, в котором установлено большое количество плагинов, т.к. с их числом растет и число вызовов хуков. Уменьшение потребления памяти вряд ли можно ожидать, но прирост по скорости, который по тестам составляет 11% побуждает к поиску дальнейших оптимизаций.

P.S. Такие же вызовы, но только для екшенов есть в классе Action.class.php в 169 и 171 строках и в роутере Router.class.php в 265, 267, 281 и 283 строках. Если и их отключить, то можно ожидать ещё более значительный прирост по скорости. Приведу лишь результаты времени выполнения такой доп. модификации (память практически не уменьшается):

  • Время инициализации модулей ЛС: 0.131 сек.
  • Полное время выполнения: 0.379 сек.

В результате имеем общий прирост по скорости на 0,0752 сек что составляет уменьшение времени загрузки сайта на 16,6%.
Конечно, данное решение нельзя назвать универсальным, т.к. оно урезает часть возможностей для разработчиков, но для тех, кто использует ЛС как фреймворк, этот топик является таблеткой для увеличения производительности.

Всем спасибо за внимание.

Это кросспост из гида по движку.

Тикет на гитхабе github.com/livestreet/livestreet/issues/200

P.S. Текст касается оф. ЛС 1.0.1.

28 комментариев

avatar
Главный вопрос, существуют ли плагины использующие данные хуки. А так да, экономия. Есть мысль не комментировать, а вынести в конфиг, если конфиг к тому времени уже определен.
avatar
хорошая идея. будем ждать чтобы разработчики отписались кто использует этот механизм, если таких не будет, то можно вполне обсудить вынос в конфиг опции, которая отключает такой вызов хуков, тем самым ускоряя загрузку сайта.
avatar
Может Максима попросить, чтобы каким-нить поиском в каталоге плагинов глянул. Сдается мне, это очень редкая штука.
avatar
Плагины такие есть. Слёту назову плагин «SEO», который очень распространён.
avatar
да, он использует этот хук, но его можно безболезненно перевесить на более ранний хук
topics_list_show

или (предпочтительней!) и правильней на

template_html_head_begin
avatar
Его и на Inherit можно перевести, но вопрос-то не вот что его можно поменять. Можно. Вопрос в том, есть такие плагины или нет. Ответ — есть :)
avatar
да, есть. но если их мало, то можно переделать. когда был переход с 0.5 на 1.0 то и блоки поменяли и текстовки и ничего — адаптировали. так можно и сейчас, тем более если это дает прирост в скорости.
avatar
Моя точка зрения в том, что плагинов и так, в общем не много. Изрядная их часть по сей день на 1.0.1 не переведена. Еще одну обратную несовместимость вводить — ещё часть плагинов терять. В идеале, наверное, нужна опция на уровне фреймфорка включающая/выключающая поддержку хуков этого типа. И дальше все в руках вебмастеров сайта. Хочешь повысить производительность — вырубай эти хуки в конфиге и отказывайся от использования соответствующих плагинов. Не хочешь — не вырбай, но зато выбор плагинов шире. Как-то так.
avatar
В идеале, наверное, нужна опция на уровне фреймфорка включающая/выключающая поддержку хуков этого типа.
вот это предложение я на гитхабе и запостил.
avatar
что есть в этом случае пиковое потребление памяти?
avatar
Отличное начинание. Было бы неплохо также обратить внимание на нередкую парадоксальную ситуацию, когда движок с включённым кэшем работает медленнее, чем с отключённым.
avatar
все зависит от типа кеша: файловый или мемкеш. первый может медленнее иногда работать.
avatar
я наблюдал замедление в обеих случаях
avatar
У нас даже файловый кэш скорость генерации страниц подымает в два раза. Весь вопрос в вашем железе. Если у Вас, например, виртуальный сервер, то причины такого поведения кэша могут быть легко объяснимы.
avatar
дело не в железе, с ним порядок
avatar
PluginMainpreview
$this->AddHook('topic_add_after','SaveTopic');
$this->AddHook('topic_edit_after','SaveTopic');
avatar
Это совсем не то…
avatar
Увидел что собираются отключить это:
$this->Hook_Run($sHookPrefix.'before');
$this->Hook_Run($sHookPrefix.'after');

Подумал что вдруг отключат хуки типа topic_add_after и topic_edit_after, а в детали не вдавался.
Но раз не то, значит все ок…
avatar
Ставим php 5.4 + APC и смотрим на ускорение и потребление памяти :)
avatar
остроумно?
avatar
Суровая правда жизни, во всяком случаи мои сайты чувствуют себя лучше ;)
avatar
Установка и даже тюнинг APC ни дали нашему сайту ровным счётом ничего. Вреда, правда, тоже не принесли. По разному бывает, однако.
avatar
Ну у меня у всех сайтов память упала с 10 до 1-2 мб, время тоже в несколько раз. Сайты разношерстные и самописы и yii
комментарий был удален
комментарий был удален
комментарий был удален
комментарий был удален
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.