phpBB Guru 4.0-dev development board

обсудим потребление ресурсов и скорость генерации страниц новой версией?

К вопросу о производительности. Многие, чтобы оценить время генерации страницы, включают режим DEBUG путем раскомментирования соответствующей строки в config.php.

Для phpBB 3.1 этот способ не работает, так как в режиме отладки отключается кэширование.

В результате разница в производительности в режиме отладки по сравнению с обычным режимом может достигать нескольких раз.

Пример: на локальной машине (Win 8.1 / Apache2 / MySQL 5.5 / PHP 5.4.3, оптимизации и опкэши отсутствуют) разница составляет 1,5 сек против 0,4 сек.

Хотите испытать реальную производительность - отключите режим отладки.

Для проверки времени генерации страницы можно использовать сторонние инструменты, например, XDebug.

А что тут собственно обсуждать?
Все в футере

Отправлено спустя 0 часов 1 минуту 3 секунды:
К тому же где-то в главной свалке мы, кажется, уже что-то такое обсуждали

Кстати.
На главной основное время уходит на обработку PHP.
На остальных страницах примерно половину времени занимают запросы в БД, из которых до процентов 90 времени (в зависимости от страницы) уходит только на 1 запрос - обновление записи в таблице сессий для текущего пользователя, куда пишется текущая страница, на которую перешел юзер. Например, тут данный запрос занял 0.05682s из общих 0.09919s. Еще 0,03 с занял запрос обновления числа просмотров темы.

Устроил тут беглое стресс-тестирование 3.0 vs 3.1 на очень зажатой по ресурсам VPS.
Чтож, вывод довольно интересный (но не факт что точный - тестирование было весьма поверхностным) - 3.1 (естественно!) "хочет" больше памяти, но, несмотря на заметно больший PGT, она более... эм... эластична чтоли.Тогда как 3.0 уперлась в производительность СУБД и, нарожав достаточно форков апача, чтобы сожрать все ресурсы, тупо взвисла, 3.1 продолжала работать, хотя и отставая в скорости продвижения по скрипту тестирования.
Итог? 3.0 "упала", выполнив 90% теста за 127 секунд, 3.1 прошла тест полностью за 279 секунд. Залог успеха - свободная память.

Очевидно, большое время компиляции кода и генерации страниц тут благо - дает базе "отдохнуть". Проверим эту догадку позже на тесте с кешерами опкода.

Отправлено спустя 0 часов 1 минуту 7 секунд:
rxu, то есть есть задел под phpBB на стероидах?

Mr. Anderson
по поводу давно обсуждали - время идет, ситуация должна улучшаться.
а можно, пожалуйста огласить параметры впс и сценарий теста?

rxu
под виндусом есть тулза которая позволяет посмотреть что читает процесс, мой php начитывал для 3.1 порядка 30-40 файлов то ли для индекса толи для вьютопика точн оне помню, малось удручает

ostridm писал(а):ситуация должна улучшаться

Почему? Приницпиально ни код, ни его объем, ни парадигма не меняются.
Какие-то оптимизации, конечно, будут, но они дадут совсем семечки - вы просто на объем кода посмотрите или на количество файлов в дистрибе.
Тут только кешер опкода поможет. Я вот может сегодня apc включу - посмотрим на результат, раз уж от eaccelerator 3.1 (пока?) рушится

ostridm писал(а):а можно, пожалуйста огласить параметры впс и сценарий теста?

Что-то вроде 1000МГц, 512Мб + адский тюнинг всего, что только можно.
Сценарий простой:
Постится 5000 сообщений, с ростом "процента выполнения" растет и количество отправляемых в единицу времени сообщений.
Скрипт написан на коленке и во многом костыльный, надо переделывать. Насколько его результат репрезентативен - вопрос очень спорный.

сколько потоков постят сообщения?

ostridm, в смысле от скольки юзеров?
От 1 до 10 же

Mr. Anderson, у нас сейчас страницы не быстрее стали грузиться?

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