Время генерации страницы

Не понял смысла? Время генерации страницы зависит от скорости моего соединения?

Ergo, вот видите, базы отличаются.

Ну бывает так что страница генерируется не в промежуточный буфер а сразу передается клиенту. Может конечно в ПХП так не бывает, но я сомневаюсь что это эффективно писать 350 кбайт в память а потом передавать клиенту.

В общем понял. Попросил людей с быстрым каналом проверить скорость генерации страницы и все стало на свои места. Спасибо всем за беспокойство :)

Скорость упиралась в канал?:-)

К сожалению, топикстартер путается в показаниях. Вначале он говорил о том, что расставил по коду счетчики. Если его исследования опираются на времена счетчиков в коде - причем тут вообще канал?

В общем, это очень хороший пример того, как бессистемное тестирование без четкого понимания как работает система приводит к бессмысленным результатам.

Буферизованная передача страницы (дождался пока все сгенерируется и потом выкинул клиенту) всегда дольше чем небуферизованная (выдача идет по ходу "готовости" HTML). При этом буферизованная выдача и памяти занимает больше, т.к. резервируется буфер под текст страницы целиком.

я тоже так думал!!! Потому что даже не предполагал, что от канала может чтото зависеть. оказывается от канала все же зависит.

А как включить в апаче буферизированную выдачу?

Не все так просто... "буферизованная" выдача лучше масштабируется, так как время генерации страницы не зависит от канала и прочих внешних данных и при этом минимально. а значит обрамляющая генерацию транзакция БД выполница быстрее, следовательно кол-во транзакций в единицу времени будет меньше. А проблему с объемом можно решить gzipом

Вы чего это такое написали? Причем тут вообще транзакция в БД и вывод готовых данных в порт? Это же не мясорубка Вам, чтобы пока фарш из шнека не вышел нельзя было мясо запихать в неё.

Генерация страницы это ОТДЕЛЬНАЯ вещь, которая зависит от скорости работы процедур в БД и скорости работы скриптов. Все. Точка. Никак с каналом и тем более с моделью вывода это дело не связано вообще.

Небуферизированный вывод тоже имеет свой буфер. Продолжим пример с мясорубкой:

Имеем мясорубку (приложение) и конвейерную ленту (канал), на которую падает фарш (данные). Конвейерная лента ссыпает готовый фарш в кастрюлю (браузер клиента).

БУФЕРИЗИРОВАННЫЙ ВЫВОД

Конвейер стоит. Мясорубка молотит мясо. По окончании перемалывания лента включается и ГОРКА фарша едет к кастрюле куда и высыпается. Не мгновенно высыпается, но быстро. Имеем задержку между началом перемалывания и началом поступления фарша в кастрюлю равную времени приготовления фарша (времени работы мясорубки). Итого время получения последнего байта данных (TTLB) на клиенте будет равно времени работы скриптов (мясорубки) + времени доставки всех данных.

НЕБУФЕРИЗИРОВАННЫЙ ВЫВОД

Мясорубка рубит фарш, конвейер включается СРАЗУ по попаданию фарша на него. Таким образом фарш попадает в кастрюлю постепенно, то есть первые кусочки фарша попадут в кастрюлю раньше чем при буферизированном выводе. Но время прихода остатков фарша будет ТАКИМ ЖЕ.

То есть другими словами НЕБУФЕРИЗИРОВАННЫЙ вывод только уменьшает время ожидания первого байта клиентом. Если файл большой, то он будет отображаться "постепенно", по мере генерации контента на серверной стороне. А при буферизированном - все и сразу после задержки.

Про GZIP - проблему с объемом надежно так решить нельзя, т.к. далеко не все клиенты поддерживают gzip сжатие, несмотря на заявления производителей (из личной статистики).

Это не принадлежность Апача, хотя я не уверен что в его настройках нельзя это включить/выключить. В Perl достаточно выставить строку $|=1 чтобы выдача была небуферизированной. Поищите поиском.

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