Привет!
у меня такая вот проблема:
скрипт генерирует страницу, и если результат (полученная страница) получается менее 200кб (допустим 194кб), то скрипт этот по временным замерам выполняется менее чем за 0.0010 секунд, но вот если результирующая страница более 200кб (допустим 215кб), скорость работы скрипта (меряю в этом же скрипте с помощью microtime()), сразу увеличивается в 6-7 раз, то есть это уже где то 0.0060-0.0070 секунд.
суть в том, что в конце скрипта подкрепляется файл через require (текстовый - txt), его размер и влияет на скорость выполнения, но я никак не могу понять в чём беда, почему так резко в 6 раз возрастает время выполнения при незначительном увеличении прикрепляемого файла. может какой буфер надо увеличить?
---
PS: файлы txt не парсятся интерпретатором, буферизацией вывода не пользуюсь, чёрную магию не юзаю, никаким богам не молюсь
Полная Версия: резкое увеличение работы скрипта
| Цитата |
| скрипт генерирует страницу, и если результат (полученная страница) получается менее 200кб (допустим 194кб), то скрипт этот по временным замерам выполняется менее чем за 0.0010 секунд, но вот если результирующая страница более 200кб (допустим 215кб), скорость работы скрипта (меряю в этом же скрипте с помощью microtime()), сразу увеличивается в 6-7 раз, то есть это уже где то 0.0060-0.0070 секунд. |
нашел о чем париться, просто забей. Или у тебя >1000 запросов в секунду?
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Что-то у меня есть подозрение, что измеряемая разность находится в пределах точности измерений А поэтому можно просто тупо проигнорить эту разность. Вот если бы вместо 0.0010 сек стало 6-7 сек, то да, тут можно было бы "париться".
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
А поэтому можно просто тупо проигнорить эту разность. Вот если бы вместо 0.0010 сек стало 6-7 сек, то да, тут можно было бы "париться".
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата |
| Или у тебя >1000 запросов в секунду? |
почему именно 1000, чтобы начать париться?
если все скрипты будут выполняться 0.001 секунд реально выйдет скорее всего, что сервак без напрягов потянет куда меньше 1000 запросов в сек
плюс к этому на серв постоянно долбятся жадные боты, их тож надо не забывать обслуживать без ахов и охов
но на самом деле уменьшение времени работы это уже как бы самоцель
| Цитата |
| Что-то у меня есть подозрение, что измеряемая разность находится в пределах точности измерений |
да тож берегу эту гипотезу пока
| Цитата (oddberry @ 5.10.2013 - 03:13) | ||
почему именно 1000, чтобы начать париться? если все скрипты будут выполняться 0.001 секунд реально выйдет скорее всего, что сервак без напрягов потянет куда меньше 1000 запросов в сек |
да просто от фонаря цифра; смысл моего коммента был в другом: разница настолько незначительна, что при невысоком рейте она не играет никакой роли и, как заметил sergeiss, находится в пределах погрешностей.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (sergeiss @ 4.10.2013 - 20:46) |
| Что-то у меня есть подозрение, что измеряемая разность находится в пределах точности измерений |
У меня была похожая ситуация, и тоже "порог" лавинообразного прироста времени (и потребления памяти) был в районе 180 кб.
Вылавливал "вражину" муторно: после каждой процедуры добавлял майкротайм в массив, и потом анализировал каждую процедуру на затраты времени. Таким образом была найдена регулярка, создававшая проблему.
_____________
Бесплатному сыру в дырки не заглядывают...
Здесь расположена полная версия этой страницы.