Время генерации страницы: что можно считать нормой?

[stopkran]

В одной теме недавно прозвучало утверждение: при превышении времени генерации страницы 0.1 с надо начинать беспокоиться (Обработка BBcode).

У меня 0.19. Я теперь беспокоюсь, оправданно ли тратить столько средств для генерации HTML такого размера. Можно ли улучшить результат у моего небольшого каталога товаров?

Размер HTML-страницы: 11 К
Всего php файлов (include): 38, общий размер: 412.03 K
Time (microtime): 0.198159 s
Memory_init (real): 256 K
Memory peak (real): 3584 K
PHP: 50205; apache; WINNT

Посмотрел для объективности другую страницу каталога, побольше размером. Странно, что размер конечного HTML практически не влияет на время генерации:

Размер HTML-страницы: 38 К
Всего php файлов (include): 39, общий размер: 425.97 K
Time (microtime): 0.17631 s
Memory_init (real): 256 K
Memory peak (real): 3840 K
PHP: 50205; apache; WINNT

Сильно ли это плохие результаты? Точнее, насколько сильно стоит суетиться, чтобы их улучшить?

 

[Adelf]

Где такие результаты? На девелоперской машине на винде?
На серваке под линуксом и любым оптимизатором значения наверняка будут на порядок меньше.

 

[AnrDaemon]

Вы забываете включить в свои вычисления время, затраченное на обращения к БД. (Не удивлюсь, если 99% указанного времени ваше приложение ждёт ответа сервера БД.)

 

[radioheaded]

* если это не боевая тачка, то измерьте на боевой
* а теперь возьмите ab и включите хотя бы 10 конкурирующих запросов

Если ваш сайт интересен кому-то, то юзеры подождут и 0.1, и 0.5 и даже 1 секунду, не сомневайтесь. А если ваши страницы генерируются за 1 мс, но при этом он никому не нужен, то вот где надо начинать беспокоиться.
Нет никакого стандарта времени генерации страницы. Визуально пользователю должно быть комфортно. Проверьте на своих знакомых: если после теста они не спрашивают «а чо так тормозит?», то пока все нормально.

 

[флоппик]

В одной теме недавно прозвучало утверждение: при превышении времени генерации страницы 0.1 с надо начинать беспокоиться

Наивно считать это показателем. Пользователи считают «ощущения» медленности, а не скорость генерации. Если даже страница сгенерилась за 0.00001 секунду, но отдавалась ему на мобильник 20 секунд по жпрс — это «медленная страница».

 

[Adelf]

Вы забываете включить в свои вычисления время, затраченное на обращения к БД. (Не удивлюсь, если 99% указанного времени ваше приложение ждёт ответа сервера БД.)

И? Какой смысл в этих словах? С БД или без БД - если сайт отдается медленно, то он отдается медленно.

Если ваш сайт интересен кому-то, то юзеры подождут и 0.1, и 0.5 и даже 1 секунду, не сомневайтесь. А если ваши страницы генерируются за 1 мс, но при этом он никому не нужен, то вот где надо начинать беспокоиться.

Разумное зерно есть, но ожидание в секунду распугает очень большую часть аудитории. Клиентская(как и серверная) оптимизация - важная вещь.

 

[Фанат]

Дело не в пользователях. А в примерной оценке оптимальности.
0,2, имхо, уже многовато.
Надо посмотреть, кто жрет все это время.
Генерация страницы, как здесь правильно заметили, состоит из различных этапов.
Вот этапы и надо смотреть.

 

[stopkran]

Дело не в пользователях. А в примерной оценке оптимальности.
0,2, имхо, уже многовато.
Надо посмотреть, кто жрет все это время.
Генерация страницы, как здесь правильно заметили, состоит из различных этапов.
Вот этапы и надо смотреть.

Вот этапы как раз меня и беспокоят . Проблема в том, что на приведённых страницах всего по 1-2 запроса к БД (ну, не считая set names всяких). Время на запросы (вообще на извлечение массива данных) не очень большое:

: Get-Data: 0,002429 s. Type: Mysql Таблица: files, параметры: (topic: 'bazalt_c'), rows:9;

Получается, что как раз 90% времени уходит на обработку данных уже в php. Страницы сами по себе не очень сложные. Мне это подозрительно - что на простых страницах какой-нибудь шаблонизатор работает дольше, чем обработка mysql-запросов. Так вообще бывает? Или надо считать это проблемой и срочно всё переделывать?

 

[stopkran]

Где такие результаты? На девелоперской машине на винде?
На серваке под линуксом и любым оптимизатором значения наверняка будут на порядок меньше.

Да, на хостинге результаты лучше:

Всего файлов: 39, общий размер: 425,33 K
Time (microtime): 0,087382 s
getrusage[ru_utime]: 0.77988 s
Memory_init (real): 256 K
Memory peak (real): 5376 K
PHP: 50217; apache2handler; Linux

 

[stopkran]

Проверьте на своих знакомых: если после теста они не спрашивают «а чо так тормозит?», то пока все нормально.

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

Вот я и хочу спросить совета, на что обычно народ ориентируется в плане оптимизации, что считается плохим, что хорошим. Конкретно в этой части: время генерации HTML страницы на сервере (не загрузка картинок, не проблемы плохой связи, не тормоза jQuery...)

 

[fixxxer]

измерять надо на линуксе и с включенным опкод кэшером

измерения на винде и тем более без опкод кэшера не имеют никакого практического смысла

 

[stopkran]

измерять надо на линуксе и с включенным опкод кэшером

измерения на винде и тем более без опкод кэшера не имеют никакого практического смысла

двумя постами выше приведены измерения на хостинге (надеюсь, у них включён опкод кэшер)

 

[fixxxer]

ну видишь разницу же не о чем пока беспокоиться

а искать узкие места удобно xdebug-ом
http://xdebug.org/docs/profiler

 

[Absinthe]

А в примерной оценке оптимальности.
0,2, имхо, уже многовато.

На винде в dev-окружении это не многовато, а очень круто Потому что в итоге на сервере будет не более 0.01

 

[stopkran]

На винде в dev-окружении это не многовато, а очень круто Потому что в итоге на сервере будет не более 0.01

Нет, на сервере 0.09. Это, может быть, круто, если на странице штук 5 меню, список новостей, акция со скидками и ещё пяток довесков типа "Здравствуйте, Пользователь!". Но если время на извлечение всех данных для страницы 0.01 (и сама страница размером 20 К), то меня начинает интересовать, куда деваются остальные 0.08 - не слишком ли велики накладные расходы на всякие там конфиги?..

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

 

[hell0w0rd]

stopkran
Все что парсится с файлов - должно кешироваться. Ответы базы тоже лучше кешировать по крайней мере самые частые

 

[stopkran]

hell0w0rd, где кэшировать то, что "парсится с файлов"? в других файлах?

 

[Adelf]

stopkran
Наводящий вопрос номер 2: стоит ли на сервере оптимизатор.

И совет: не оптимизируй ничего до тех пор, пока это не доставляет неудобства кому-либо.

 

[hell0w0rd]

hell0w0rd, где кэшировать то, что "парсится с файлов"? в других файлах?

а где возможности позволяют, вот удобный инструмент, хотя есть и другие аналоги:
https://github.com/doctrine/cache
PS если когда нибудь примут PR будет удобная возможность (подсмотренная в yii 2) общаться с кешем через arrayaccess

 

[Фанат]

stopkran
Все что парсится с файлов - должно кешироваться. Ответы базы тоже лучше кешировать по крайней мере самые частые

hell0w0rd
а ты сам кэшируешь? часто? что конкретно?