Медленные модули в Yii?

Question

[Nks]

Используемый фреймворк: Yii (как ни странно)).

Столкнулся с проблемой: медленные модули. При том из профилирования не понятно какой из них медленный. Запросы к БД есть, но они не такие медленные, как суммарная загрузка страницы (2 сек). Хотелось бы снизить до 1 сек. или хотя бы ближе к этому числу.

Итак вот картинка.

Из лога мы видим, что после включения компоненты сессий сразу же идет +2 сек. Отключение проверки isGuest() в right.php (там все видно) не дает прироста ни в чем. Тогда сразу же следующий запрос, после предыдущего, начинает грузиться через 2 секунды. Профилирование запросов к БД дало следующий результат: картинка здесь.


Пробовалось на 2-х вариантах железа: результат одинаковый.

Answer 1

[egorinsk]

Профилируйте нормальным инструментом, например, XDebug, для сравнения сделайте лог нормальной (нетормозящей) страницы и тормозящей, и сравните. Модули же могут ставить свои хуки на разные события. По приведенным данным трудно что-то сказать. Запросы к Бд, видимо, тут не при чем.

Comments

[Nks]

Профилирование средствами yii было сделано только после того, как с помощью firebug я увидел огромные цифры по загрузке. При использовании встроенных средств профилирование задержка увеличилась всего лишь на 40-50 мс.

Answer 2

[Александр Макаров]

Как у вас хранится сессия? Что-то на инициализацию ушло неприлично много времени.

Comments

[Александр Макаров]

А, не не много.

[Александр Макаров]

yiiframework.ru/doc/guide/topics.performance
это всё уже сделано?

[Nks]

Включив yiilite.php и apc получил желанную загрузку в 212 мс. А где-то и меньше. Спасибо.

[evnuh]

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

[Nks]

Проблема была, как всегда, в человеческом факторе. Я получал запрос с удаленного сервера через oauth и, чтобы не сильно заморачиваться встроил в один из view функцию запроса к этому серверу. Скорость доступа до сервера примерно секунда вместе с обработкой полученных данных в количестве где-то 2000-3000 строк. В итоге этот запрос и тормозил всю работу. Сейчас все работает очень быстро.

[Алексей Сундуков]

Очень быстро в цифрах это сколько? Просто любопытно, какое время генерации страницы в данном случае считается приемлемым (212? просто из контекста не очень понятно).

[Nks]

В пределах 250 мс. при 13-25 обращениях к бд. При том, что большинство времени это и есть работа с бд, т.к. файловая подсистема на машине все же оставляет желать лучшего, но это уже проблема физическая.

Answer 3

[Lebnik]

а у кого какая скорость работы Yii без базы данных и APC? так скажем чисто вывести Hello Word

Comments

[balloon]

Недавно эксперементировал. Просто приложение: категорий, в них посты, в постах комменты. Схема базы и все запросы закешированы (файловый кеш). Сервер на rackspace с 2Gb RAM. Стек: nginx + php-fpm + php5.4.

[balloon]

В результате получилось для страницы со списком постов и кол-во комментариев:
— без xcache: ~70 req/s при 50 конкурентных запросах
— с xcache: ~150 req/s при 50 конкурентных запросах
Проверял через ab.
Пробывал кеш базы тоже в xcache засунуть — практического эффекта не дало. iotop показало что диск не используется. Имхо, все в cpu упиралось. Так больше 150 и не разогнал. Может у кого еще идеи есть по поводу оптимизации.

[balloon]

Еще была попытка сгенерировать все классы в один файл для уменешений обращений к xcache (так же как yiilite.php только для всего приложения). В результате получился файл в 360Kb (opcode на 5.4Mb). На странице только с инклудом этого файла и с теми же 50 конкурентными запросами потолок составил 220 req/s.

[Алексей Сундуков]

Измерять в req/s без указания количества рабочих процессов не очень корректно. Потому как можно за nginx-ом пустить пачку апстримов и весь вопрос будет в количестве используемых серверов. ab для нагрузочного тестирования тоже не самый хороший инструмент. Более гибкий и мощный это httperf. Пример использования тут: "Smarty VS ctpp".