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

stealthy, все что вы написали верно если сначала собираются данные, а потом на основе этих данных генерируется страница. Если же данные выбираются из базы по мере генерации страницы, то обрамляющая транзакция будет достаточно долгая.

Про gzip я писал в следующем смысле:

1) можно сделать кэш страниц а не генерировать их каждый раз

2) страницы в кэше можно хранить сжатыми

3) при необходимости распаковывать

ЗЫ. Буферизовнный вывод сложнее в реализации нежели небуферизованный (знай себе пиши в сокет байты). Так зачем городили огород с созданием буферизованного если у него нет преимуществ.

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

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

Про gzip - я не спорил о методах реализации, у нас в системе все так и сделано как вы перечислили за исключением третьего пункта - он не нужен. Просто я сказал что gzip может не спасти, если клиенты его не понимают. А в остальном возражений нет.

Это Ваше определение времени генерации. Для меня этот термин означает совершенно другое. В моем понимании есть время ответа сервера, время генерации страницы и время передачи страницы от клиента к серверу.

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

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

ЗЫ. Наиболее заметный выигрыш в производительности будет если мы при генерации страницы обновляем какой нить счетчик.

Послушайте, не путайте людей, и так тут у многих каша в голове из-за нежелания разбираться в деталях. Даже при таком понимании времени генерации страницы процесс её создания НИКАК НЕ СВЯЗАН С ЕЁ ВЫВОДОМ. Вообще. Мясорубка будет молоть мясо с одной и той же скоростью независимо от того, будет фарш из-под нее уезжать в кастрюлю или он будет там скапливаться. Вот и все.

Возьмите и почитайте как реализованы веб-приложения на системном уровне, а то пишете какую-то ересь прикрываясь умными словами типа "паттерн" и "транзакция". Или напишите свое приложение такого плана хотя бы раз. Тогда никаких теоретизирований на пустом месте не будет.

Я из дискуссии на эту тему выхожу, надоело доказывать очевидные вещи.

Вот в этом ваше заблуждение. И пример ergo это доказывает.

И давайте не будем меряца сами знаете чем. Еще ведь неизвестно у кого больше, можно и опозорица;-)

А вот здесь меня ткнули мордой в навоз и объяснили что все совсем наоброт

По ссылке видна та же проблема - вы некорректно ставите вопрос и сами путаетесь при этом. Собственно ничего в этом треде нового, по сравнению с тем что написал Вам я - нет.

Если у вас страница полностью приезжает за 10 секунд, а у другого человека на быстром канале за 2, то это время можно описать формулой:

ВремяОжиданияЧеловекаВБраузере = ВремяОтсылкиДанных + ВремяОбработкиДанных + ВремяВозвратаОтвета.

Естественно, что ВремяОтсылкиДанных можно не рассматривать из-за очень малого объема данных в запросе (обычно). Время обработки данных на сервере будет одинаковое для Вас и Второго человека что бы тут Вам не писали. ВремяВозвратаОтвета у Вас будет =КоличествоКилобайтВОтвете/СкоростьПередачиДанных.

Естественно, что если Вы увеличиваете количество выдаваемых сервером данных, то и общее время ожидания будет увеличиваться пропорционально. Поэтому если у вас канал на 64Кбит/сек, а у вашего приятеля 1024Кбит/сек, то при объеме страницы в 320Кб у Вас она будет грузиться 40 секунд, а у Вашего приятеля 2.5 секунды.

Если Вы увеличите размер страницы до 720Кб, то у Вас она будет грузиться уже 80 секунд, а у него - 5. Он просто не заметит разницы. Это должно быть очевидно даже школьнику, высшего образования для этого не нужно.

Если же Вы замерите время генерации страницы, то оно будет одинаковым на любой скорости связи.

stealthy, ну е мое! распишу тогда на пальцах

вопрос №1

у меня есть соковыжималка которая может отжимать сок со скоростью до 100 литров в секунду, от нее идет в ведро труба которая может пропустить сок со скоростью до 10 литров в секунду. Вопрос: сможет ли соковыжималка работать с максимальной скоростью 100 л/секунду?

вопрос №2

все тоже самое, но между соковыжималкой и трубой есть сосуд (или БУФЕР) достаточно большого размера.

Я и замерял время генерации страницы если вы не заметили. Если вы не согласны, то объясните что я делал не так. Я же не яваскриптом замерял скорость ее загрузки. Все вычисления делались в коде php. В начале страницы и в конце.

Мишган, Вы забываете, что буфер между приложением и сокетом есть всегда что при буферизированном что при небуферизированном выводе.

Попробуйте хотя бы себе объяснить, каким же интересно образом приложение будет медленнее генерировать код, если канал занят? С помощью какого интересно механизма будет медленнее или быстрее работать PHP (или любой другой язык взять) код, или код хранимой процедуры или SQL запроса в зависимости от занятости канала? Что, есть какие-то специальные каналы для посылки от стека TCP/IP в программу команд типа "а ну ка помедленнее, братишка, я печатать в сокет не успеваю"?

Короче, возьмите напишите себе программу и посмотрите как она работает, чего вы меня убедить пытаетесь в своих заблуждениях? Я все это 7 лет назад на практике прошел когда мы делали баннерную крутилку с производительностью на 6 миллионов показов в час.

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

Вы объясните что Вы делаете людям, а потом совет спрашивайте. Вы код привели? Я вам дал ссылку на профайлер, если Вы им пользовались - что он Вам показал? Где план Вашего тестирования, то есть что именно Вы исследуете и какой результат хотите получить? Извините меня, конечно, но мне кажется что Вы подходите к серьезному вопросу бессистемно, а все приведенные в топике советы попросту игнорируете.

Читая обрывочные сведения в этом топике я могу предположить, что Вы добавляете в страницу не HTML код, как Вы говорите, а Вы пробуете выводить разное количество каких блоков на странице которые берутся вероятно из базы. Естественно СЛЕДСТВИЕМ этого является увеличение количества HTML кода. Естественно и то, что при выводе 3 блоков и 5 блоков с данными из базы на странице у вас могут увеличиваться затраты на выборку данных из базы или затраты на обработку данных (в слове бизнес-логики). Это зависит уже от архитектуры приложения. Если это так, что удивляться, что приложение дольше работает при выводе 5 блоков в отличие от 3 нет смысла - это естественно. Нужно брать каждый блок вывода и смотреть - сколько времени он работает и почему.

Если я в предположениях ошибаюсь - извините, сами ничего толком не пишете.