Функция echo в PHP может выполняться более 1 секунды

[chip]

Так и на чем остановились? Бить на блоки?

PS: у вас meMMory, вместо meMory

[gnomeby]

Спасибо, подправил.

Нет, пока на: php_flag output_buffering = On
Чтобы основная логика обрабатывась без тормозов

[fstab]

спасибо, интересно было прочесть.
Но правильный синтаксис для директивы все-таки по-моему
php_flag output_buffering On, а не
php_flag output_buffering = On

[skazkin]

Нипанимаю насчёт мнимой таблетки. Кусок-то меньше 18 кибов? В чём возникла проблема?

[gnomeby]

Ах, да.
В том что при применении «мнимой таблетки» проблема решается только при суммарной отдаче не более 18 Киб. в моём случае.

[skazkin]

суммарного echo?
то есть 4 echo, каждый отдаёт по 5 кибов — это уже затык?

[gnomeby]

Да, на 5-м.

[gnomeby]

исправил, спасибо.

[iBear]

Прочитав:
функции echo и print на самом деле могут работать очень долго и их производительность зависит от качества интернета конечного пользователя

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

[Iv8]

Ни что иное, как проблема медленного клиента.
Попробуйте файлик размером в один мегабайт отдать через readfile(), это может занять минут пять-десять через GPRS.

[kvf77]

А не пробовали воспользоваться парой ob_start(); ob_flush();?

[toxaus]

Тоже интересует, почему не пробовали.

[gnomeby]

В CakePHP всё кроме последнего вывода примерно так и оборачивается. Просто данной конструкцией мы переносим проблему в конец.

[odessky]

А теперь попробуй поставить nginx перед apache и повторить тест

[smartly]

следующим шагом будет убрать apache оставить nginx :)

[Regis]

При фиксированном размере буфера — ничего не изменится.

[Urevic]

Изменится еще как, apache все максимально быстро сбросит на nginx и он уже будет отдавать контент медленному клиенту одним легким тредом, а тяжелый процесс апача будет уже готов обслуживать нового клиента.

[Regis]

«apache все максимально быстро сбросит на nginx»
Ха. И еще раз ха.

Угадайте, где теперь буфер? Правильно, на nginx. Если такой же буфер выделить для самого PHP, то будет то же самое. Единственное, что PHP сможет полностью закрыться, а не оставаться в фазе закрытия, что позволит сэкономить еще немного памяти.

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

PS: Хотя конечно nginx для непосредственной отдачи намного лучше апача в отношении использования ресурсов.

[Regis]

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

[Urevic]

> Хотя конечно nginx для непосредственной отдачи намного лучше апача в отношении использования ресурсов

Так вот именно в этом-то и дело. Чтобы не быть голословным, приведу пример. Есть маленький VPS с 128 Мб RAM, в памяти висят сейчас 4 процесса апача (апач конечно же в prefork mode, т.к. mod_php). 3 процесса жрут каждый по 12% RAM, четвертый 5% (мастер видимо), согласно top. Nginx жрет всего 0,6% RAM. Если будет много запросов к апачу, с которыми не справятся уже поднятые 3 процесса (будут ждать медленных клиентов в этот момент), то апач начнет поднимать новые процессы, каждый из которых тоже быстро наберет жирок и тоже будет занимать около 12% памяти. В моем случае это все грозит залезанием в своп и просто жуткими тормозами.

Буфер конечно никуда не денется, он будет в nginx, но буфер это ерунда по сравнению с новым процессом апача со всем его модулями.

[lasc]

А еще на OpenVZ VPS, нет свопа и дело принимает совсем печальный оборот

[alekciy]

mod_php нормально работает и в worker-е (другой вопрос, падение дочернего со связкой тредов...).

Но лично я даже с worker-а ушел, т.к. при nginx+php-fpm мы совсем избавляемся от apache.

[wackum]

А после этого попробуй выкинуть PHP и поставить Python.

[dfuse]

Это слишком радикально :)

[wackum]

Это слишком умно, чтобы современное поколение Хабра на это пошло, судя по оценкам.

[dfuse]

Да нет, просто статья то о PHP… Я вот свой плюсик поставил…

[maserg]

это даже очень слишком мега умно… интересно, кто первый здесь напишет rubyonrails, java или с++…

а что, mod_python как-то по-другому работает? автор какбе «в курсе», или автор просто хотел сказать что он реально «серьёзный разработчик»?

[proxor]

Обычно веб-приложения на Python развертывают через FastCGI или WSGI. В связке с lighttpd или nginx. Apache отсутствует как факт.

[maserg]

ничто не мешает точно так же запускать и php… от этого мой вопрос к автору не поменялся

[Bal]

Аналогично, например, у меня на сервере в связке lighttpd + php-fcgi Апач отсутствует как факт.

При чём тут языки?

[wackum]

mod_python никто не использует для нормального деплоя. только mod_wsgi. Учите матчасть.

[maserg]

вы мне на вопрос ответьте, а не давайте свои мега-советы про матчасть.

здесь какбе речь идет про mod_php, появляетесь вы и говорите очень умную везчъ «выкинуть PHP и поставить Python», после чего доносите до нас знания про mod_wsgi.

даже не знаю… «скажи наркотикам нет...»

[nekt]

Мы нгинксом только и спасаемся от таких проблем :)

[Bonch]

Встречался с подобным. Делал так:

[Bonch]

print $out;
flush();

[kvf77]

ну и как это поможет если тормозить будет перед flush?

[Goodkat]

может быть так?
ob_start();
print $out;
ob_flush();

тогда print всё отдаст быстро, а тормозить будет уже flush :)

[dfuse]

Вроде того, я думаю.

[Bonch]

Ну да. Просто у меня весь вывод из скрипта накапливается в $out, а не выводится сразу. Поэтому и использую flush()

[Goodkat]

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

[Alvego]

Спасибо. Интересная статья. Нужно будет протестировать свой код подобным образом.

[coldFlame]

Вот потому-то и нужен проксирующий сервер

[payalnik]

за что минусят этого комментатора? Он совершенно правильно говорит. Поэтому люди и спаривают apache с реверс-проксей на nginx

[serkys]

Возникала у меня такая проблема, echo больше секунды выполнялся. Решил её gzip-сжатием отдаваемого контента.

[kvf77]

Это все круто, если бы все браузеры нормально это понимали.

[Shiz]

хм, всегда удивляло такое примечание. а какие браузеры не понимают заgzipованую страницу?

[dfuse]

Не поверишь, IE6 )))

[SkyCat]

Нормально он понимает. Бывают некоторые проблемы, но уж на слишком экзотических задачах. На обычном сайте все работает нормально.

[dfuse]

support.microsoft.com/default.aspx?scid=kb;en-us;823386&Product=ie600 я бы не называл это «некоторыми проблемами в экзотических задачах»…

When Microsoft Internet Explorer receives compressed HTTP data, you may experience one of the following problems:

— HTML pages may only partially appear, or the pages may not appear at all.
— Your HTTP connection may stop responding.

Саuse: This behavior occurs because Internet Explorer does not read all the data in the HTTP response.

[SkyCat]

Возможно, я ошибаюсь и очень сильно. Если у вас есть рабочий IE6 под рукой, не смогли бы вы один сайтик проверить? У меня deflate включен для всех браузеров, без указания т. н. «старых».

[dfuse]

Давайте ссылку — на работе стоит Multiple IE, в пн проверю… Дома виста, поэтому тулзу не поставить толком :(

[neytrino]

Для висты существует подобное:
www.my-debugbar.com/wiki/IETester/HomePage

[SkyCat]

Спасибо. Я как раз ей и пользуюсь. К сожалению, там нет возможности смотреть http-заголовки. Чисто визуально в этой программе IE6 на моем сайте прекрасно со сжатием работает.

[GrustniyKot]

спасибо!

[SkyCat]

Оправил вам в личку. :)

[serkys]

Советую поставить Multiple IE, очень удобно.

[BisnoyZakat]

у меня safari не понимает gzip контент.

[dfuse]

быть того не может… Сжатие DEFLATE он точно поддерживает, значит и GZIP тоже должен. Посмотрите Ваши настройки.

[Regis]

Неужели у вас настолько старая версия сафари? :)

[dfuse]

Подумал еще разок — может тот скрипт, что отдает GZIP просто не ставит соответствующие заголовки Content-Encoding: gzip? Это тупо конечно, но другой причины я реально не вижу, по крайней мере с серверной стороны.

[Regis]

Так вы посмотрите, что на клиент приходит.

[dfuse]

Дык эт вы не мне пишите ))) У меня то все ок, только что проверял Safari 3

[Regis]

Тьфу :)

[yuretsz]

Браузеры, обычно, об этом сообщают через Accept-type

[crazyprog]

Не знал. Большое спасибо! Нада будет заняться тестированием.

[IntenT]

это же надо было так долго и путанно объяснять, что вода мокрая и 2х2=4…
статья из серии — есть клюнуть себя в жопу — будет больно

[RedOctober]

молодец автор, расписал красиво.

[cuprum]

некий Nagle aLgorithm

[magicstream]

что если выводить контент таким образом: ?>контент контент контент<?

[magicstream]

я не понимаю зачем минуснули. дело в том что как я понимаю проблема не именно в функции echo или print. Данная ситуация должна происходить при любой отправке контента клиенту

[bolk]

ob_start

[Regis]

Не понимаю нападок на «Nagle's algorithm». Очень уж отдаленно он связан с проблемой. Его суть сводится лишь к тому, что не посылаются пакеты слишком малого размера, а чуть чуть придерживаются, пока не наберется большой пакет. И всё.

У вас же проблема прямо-таки противоположная — вы хотите сразу послать много больших пакетов, да вот только клиент их не может принять. А пока он пакеты не принял, вам их нужно где-то хранить. Где? Правильно в буфере вывода PHP. Да вот только буфер тоже не резиновый (по умолчанию). Как следствие — приходится полностью останавливать PHP, чтобы он нам не переполнял этот буфер. Последствия вы уже описали.

Проблема вызвана не использованием накопления пакетов («Nagle's algorithm»), а тем что мы не можем мгновенно перебросить клиенту всё, что нагенерировал наш PHP код. И эта проблема как была так и останется. Всё что можно с ней разумного сделать — выставить размер буфера в соответствие с размером страниц сайта.

PS: Выставлять неограниченный буфер — на самом деле довольно плохая идея. Буфер должен быть большим, но не резиновым.

[Regis]

Кстати, в комментариях к статье, на которую ссылается автор, тоже высказывают непонимание относительно того, при чем тут этот алгоритм. Кстати, там есть отсылка к его спецификации.

[dfuse]

Суть, как я понял, в том, что РНР притормаживает при отдаче print'ов и пока не отдаст их юзеру дальше не выполняется, так?

А если, допустим, вначале скрипта поставить размер буфера на 30-40К, включить ob_start и держать его до самого конца ничего не отдавая, и отдать уже в самом конце одним куском в самом-самом конце работы — решит ли это проблему?

[dmiceman]

Я вот даже как-то не понял — а в чем проблема-то? Юзер все равно не увидит конечный результат раньше чем страничка прокачается через его соединение. Соответственно, мнимая задержка на echo никакого влияния на конечный результат не окажет.

[dfuse]

Логично предположить, что когда буфер забит, а запись в него все идет и идет, то РНР начинает его отправлять, и ждет пока юзер его не заберет, соответственно ничего нового туда не будет записано. Но это мои догадки…

[Regis]

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

[Regis]

Проблема в том, что пока не закончил работать PHP — под него зарезервировано значительное количество памяти. А на серверах именно память и загрузка процессоров — основной ресурс.

[dmiceman]

Загрузка проца будет равна нулю, процесс apache будет висеть на ожидании возможности записи в декриптор сокета.
Память — да, но скорее всего это будут копейки. Ну провисят они лишние 300ms в памяти, ну и что?

[Regis]

А если клиент будет тянуть страницу по 10 минут? :)

[dfuse]

А если 10 таких запросов? 3 секунды провисания… Многовато…

[gnomeby]

В большинстве случаев, да. Но когда 9 серверов обслуживают 500000 посетителей в день, а в моменты рождественнских акций нагрузка зашкаливает и сервера еле справляются возможно это сможет помочь пользователям получать инфу чуть быстрее. А это приятно.

[Regis]

Да.

Если у вас, страница влазит в буфер — то разницы не будет: отдавать сразу или одним куском в конце. Точнее будет разница на время генерации страницы. Если страница в буфер не влезла, то в PHP останавливается, пока не будет отдано всё, что до этого нагенерилось. В любом из двух случаев накопление контента и отдача его одним куском ситуацию не улучшит. Но и не ухудшит сильно.

Основной метод решения проблемы — минимизация передаваемого объема. Так что Tidy и Gzip — наше всё :)

[dfuse]

GZIP об IE6 споткнётся, а так у меня на сайтах так и делается — сначала все в буфер, потом если есть возможность — в GZIP или DEFLATE, в результате имеем

Сжатие DEFLATE: 8.84 КБ → 2.78 КБ (68,6%)
Полное время выполнения: 0,051 сек.

[Regis]

Как насчет того, чтобы проверять заголовки, которые пришли клиента? Если клиент говорит, что скушает gzip — кормить gzp'ом, отказался от gzip'а, но сказал, что ест deflate, то deflate'ом :)

[dfuse]

Я как раз так и делаю :)

if(isset($_SERVER['HTTP_ACCEPT_ENCODING'])) $acceptEnc = $_SERVER['HTTP_ACCEPT_ENCODING']; else $acceptEnc = $_SERVER['HTTP_TE'];
$_SERVER[cmsGZIP] = array(
«enabled» => (stristr($acceptEnc, 'gzip') || stristr($acceptEnc, 'deflate'))? true: false,
«algorythm» => (stristr($acceptEnc, 'deflate'))? «deflate»: «gzip»,
);

[sunnybear]

лучше через Apache — там еще Cache-Control: private нужно выставлять

[bolk]

IE6 поддерживает gzip

[dfuse]

Я вообще то про то же

[dfuse]

Долбаный CTRL+ENTER :)

А насчет TIDY я еще не думал честно говоря… Кстати есть мнение, что нужно не только JS, но и CSS и HTML отдавать в «minified» виде. Не удобно при разработке, зато после публикования можно смело врубать.

[Regis]

Почему не удобно в разработке? При разработке храним всё форматированным, со всеми отступами для удобства. А при выставлении на продакшн настраиваем сжатие всего и вся. Не вижу проблемы.

[dfuse]

Я имел ввиду, что на этапе разработки не надо включать minify ибо разрабатывать будет неудобно. «зато после публикования можно смело врубать»

[Regis]

Ну, это и так понятно :)

[wayly]

Ну css и js кешируются, вообще говоря.
Другое дело, если вы в странице отдаете стили и код JS. Так что много все-равно не выиграете.

[Urevic]

Проблема в том, что пока PHP не отдаст апачу весь контент, который он должен отдать, скрипт не завершается. А апач в некоторых случаях не торопится этот контент принять, как считает автор. Я честно говоря это себе по другому немного представлял, но автор такие графики красивые нарисовал, что наверное стоит ему поверить.

ob_start тут никак не поможет, т.к. автор и так отдает контент в скрипте одним большим куском в конце. Поможет тут, как уже несколько раз сказали выше, установка reverse proxy (nginx или lighthttpd).

[dfuse]

Я имел ввиду, что надо отдавать в самом конце, после всей логики. Чтобы после тяжелого принта не было выполнения. Т.к. пока принт не выполнится, до того, что за ним дело не дойдет. Нам то важно, чтобы скрипт быстро отработал и отдал данные — тогда перед принтом можно и соединения позакрывать и память почистить.

[Regis]

Если в этом смысле, то в принципе да, проблему неэффективного использования ресурсов это решает. Правда в таком случае придется потратить веремя на всю эту чистку памяти и проверку, да и все же всё вы не вычистите. Проще передать это всё из PHP во внешний по отношению к нему буфер, а его (PHP) благополучно освободить.

[dfuse]

Да, по-хорошему так и надо. Но если брать в расчет шаред-хостинг, то становится тоскливо :(

[Regis]

А в чем проблема найти шаред за ngix + Apache + что вам там из БД надо?

[dfuse]

Ну я как-то больше привык сам настраивать :) потому что хрен его знает что там админы намутили… Кстати есть какие-то хорошие хостеры на примете? (лучше в личку наверно)

[ilynxy]

Да и вообще не очень понятно причём здесь PHP, apache, nginx (и, как справедливо замечено, Nagle's algorithm).

Неумеренность в буферах может привести к меньшей устойчивости к DDoS'y (условно). Впрочем, это требует исследования, на конкретных «попугаях» — куда будет быстрей расходоваться память — на создание новой копии интерпретатора или на буферизацию. Точнее отношение этих объёмов. Может быть создание копии интерпретатора потребляет памяти значительно больше, чем выделяется под буферы. Поэтому эффект от увеличения буфера может быть, в целом, положительным.

[dfuse]

Чтобы сайт был стоек к DDoS вероятно лучше пользоваться FastCGI, но только не с PHP, а допустим с Perl. Потому что перл песочницу создает однократно и надо только будет следить, чтоб не было утечек памяти, а РНР будет все равно запускаться каждый раз с нуля.

В большинстве сайтов, которые мне довелось видеть, всяческие autoexec и фреймворки грузятся зачастую дольше, чем сам скрипт работает ;). Поэтому если каждый раз экономить по 50-100 мс на подготовке, то за 100 запросов мы получим нехилую экономию. Даже при учете, что допустим сам скрипт работает еще столько же.

[dmitriyecho]

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

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

[Regis]

Да.

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

[maxcom]

Про Nagle algorithm вообще спор бесполезный, в Apache он всегда выключен за ненадобностью

[dfuse]

Да при современных каналах даже 1 байт ценной инфы может обрамляться 40 байтами заголовков и не страшно… лишь бы дошел.

[maxcom]

По большому счету да. Терминальные приложения сейчас составляют малый процент траффика, а программам передающим данные большими блоками nagle-алгоритм только мешает. Хотя раз держат его включенным по умолчанию в ОС значит чем-то это оправдано (надеюсь, не только историческими соображениями ;-)

[gnomeby]

Именно к тому, что вы написали я постепенно и пришёл. Всё верно, добавил в статью апдейт.

[Regis]

Именно. Он касается обработки малых пакетов, а не больших.

[maxcom]

в apache nagle алгоритм выключен

[dfuse]

Ничего оно не ухудшит. Почитайте википедию — там доступно разъяснено, что нужен он когда надо переслать 1 байт, а заголовков при этом на 40. Это довольно расточительно, поэтому пакет собирается по кускам и отправляется за один заход.

А у нас наоборот пакет здоровый.

[dfuse]

никто не мешает вызывать echo($str) или print($str) — не придирайтесь ;)

[propovednik]

По данным php.net
Справочник функций — Text Processing — Функции работы со строками — echo
Но пишут «На самом деле echo() — это не функция, а конструкция языка, поэтому заключать аргументы в скобки не обязательно, даже при использовании нескольких аргументов». Я в шоке :)

[gnomeby]

Просто по правилам — это конструкция языка, поскольку имеет не все свойства функции. Но для упрощения никто не мешает называть её как функцию. Если быть слишком концептуальным и вводить новое понятие в мануал, то это только запутает начинающих программистов.

[sibin]

протстил на нескольких серверах, проблемы такой не разглядел. Даже если сильно увеличть длинну вывода. Браузер виснет, а время отдачи не больше 10мс. Странно.

[Regis]

Какой размер буфера указан для PHP?

[anight]

Надо тюнить tcp_wmem, php и apache тут не при чем.

[Regis]

Почитал описание tcp_wmem. Весьма похоже на правду, что это действительно может быть основным решением.

[anight]

Да вариантов как-бы и нет ;-)
php делает echo, через всякие ob_извращения дело доходит до sapi->ub_write(), который в случае с mod_php равен php_apache_sapi_ub_write. Там вызывается ap_rwrite() в блокирующийся сокет. Если памяти в буфере недостаточно — ядро блокирует вызов пока вся запись не пройдет.
Можно подкрутить SendBufferSize, по идее результат должен быть такой же.

[Joka]

php 5.2.6
output_buffering 4096

Display Length: 28 KiB.
Reach end file: 0.12 ms.

не вижу проблем — что я делаю не так? как ощутить эту проблему?

[gnomeby]

Читайте апдейт к статье, там указано как воспроизводить даже в локали

[Joka]

я пробовал в локали и на 4-х серверах — все работает нормально — воспроизвести не удалось

[gnomeby]

Хм. А у вас output_buffering выключен? Ибо данный тестовый пример не имеет смысла если он включен. И попробуйте ещё ограничить скорост скачки.

[dfuse]

5.2.6 Буфер выключен.

Display Length: 1304 KiB.
Reach end file: 1.03 ms.

[gnomeby]

Читайте апдейт к статье, там указано как воспроизводить даже в локали.

[dfuse]

Дык вы на цифры посмотрите… я метр прокачивал уже, а глюка нет…

[gnomeby]

ну так, если включен output_buffering или используете реверс прокси, то глюка может и не быть. И в принципе это хорошо.

[dfuse]

«Буфер выключен.» прокси нет.

[sunnybear]

осветите вопрос с gzip: сейчас непонятно, помогает или нет он

[Regis]

Да, помогает. Меньший нужен буфер.

[sunnybear]

супер, буду пропагандировать gzip дальше :)

[dfuse]

Флаг в руки. Я обеими руками за. А майкрософту надо оторвать кой-чего за то, что IE6 GZIP'у не обучен. Имейте ввиду и проверяйте заголовки, я выше писал как.

[Bal]

Кроме того, канал держится меньше времени.

[xRay]

Автор такой трактат накатал

ob_start как же?

[maxcom]

Nagle-алгоритм был придуман для программ вроде telnet, в которых нажатие клавиши пользователем приводит к вызову системного вызова write(), приводящего к отсылке пакета с данными. Чтобы в сеть не летело много мелких пакетов, nagle-алгоритм немного притормаживает передачу дабы собрать идущие подряд вызовы write() в один пакет.

Приложения которые умеют нормально буферизовать вывод (а не дергают write на каждый выводимый байт) выключают nagle алгоритм путем выставления опции сокета TCP_NODELAY. При этом каждый write приводит немедленной отсылке пакета без задержек. В apache такая опция на сокете стоит практически от рождения.

Однако единственный побочный эффект, который может вызвать включенный Nagle — увеличение времени отклика сервера. К вашей проблеме это имеет весьма отдаленное отношение.

[maxcom]

Проблема которую вы на самом деле пытаетесь решить вот в чем: пока пользователь скачивает страничку с сервера, он занимает его ресурсы. Если вы его «кормите» выводом скрипта, то без буферизации скорость работы скрипта будет ограничена тем, с какой скоростью пользователь готов «есть» генерируемые им данные.

Буферизация позволяет освободить дорогие ресурсы сервера (соединения к БД, треды выполняющие PHP-запросы и т.п.) за счет более дешевых ресурсов вроде оперативной памяти. Благодаря буферизации скорость исполнения скрипта не ограничивается скоростью клиента. При этом буферизацию лучше выполнять не средствами PHP, а в веб-сервере nginx/lighttpd. За счет своей архитектуры они способны «кормить» буферизованными данными тысячи медленных пользователей практически не занимая системных ресурсов в момент ожидания готовности пользователя (главное чтобы памяти хватило). Apache подходит хуже т.к. на одного пользователя занимает тред/процесс вместе с довольно дорогим контекстом.

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

[maxshopen]

Вот блин, все б так статьи писали и оформляли. Я не программирую на php — и то зачитался.
Спасибо

[rapaman]

хорошая статья, молодец автор, подробно и доступно, с примерами.

[proxor]

Отличная статья. Я даже и не подозревал о таких проблемах :) Судя по комментариям проблема неплохо решается реверс-прокси в виде nginx?

[gnomeby]

Да, можно и так.

[jandosul]

Думал щась начнется баттл принт ето функция а ехо конструкция аннет
Спасибо автор очень занимательно и полезно

[GEMOzloBIN]

dklab.ru/chicken/nablas/50.html Обьяснение проблемы медленных клиентов и её решение

З.Ы. на теги кармы не хватает =(

[Bal]

Для профилирования очень рекомендую xdebug :) Это намного удобнее, чем ручные измерения. Получаются прекрасные и информативные отчёты, какие методы и функции сколько чего жрут:

www.xdebug.org/docs/profiler

А с идеологической точки зрения, всё же, рекомендую во-первых, буферирование выхода, во-вторых, переход к идеологии «в проекте должно быть только одно echo — вывод результата».

Ну и сам сайт хорошо бы проектировать так, чтобы динамика отдавалась небольшими кусками. А всё толстое — статикой или иными решениями, не PHP. Например, тем же mod_cml на lighttpd.

[gnomeby]

Да, я знаю xdebug, спасибо. Просто формат статей вообще препологает простые и доступные примеры. У меня есть тестовые скрипты, который меряет более правильный чем приведённый, просто не хотелось простыню постить.
Идеологии поддерживаю на 100%.

[Bal]

>Просто формат статей вообще препологает простые и доступные примеры.

Так можно было просто написать: «профилирование с помощью xdebug показало, что echo выполняет N секунд» :)

[gnomeby]

А как же самому попробывать? :-) в этом и суть, чтобы любой смог затестить за 30 секунд без необходимых затрат.

[Aux]

Вообще-то умные дядьки давно придумали, что сначала надо отработать ВСЮ логику, а потом нарисовать HTML. MVC там, все дела…

[gnomeby]

Вы невнимательны, я писал, что использую CakePHP, где всё так и происходит.

[Aux]

С CakePHP лично не знаком, так что подробностей не знаю. А если так, то в чём проблема? После финального echo кода уже не должно быть, движок должен зашатдаунен и наступить полное счастье. Ну а если есть косяки со стороны веб-сервера, то PHP тут уже ни при чём.

Я не против статьи как таковой, статья полезная ибо обращает внимание на старый подводный камень о котором многие на самом деле не знают.

[bdsoft]

а почему бы не выводить всё одним echo в самом конце скрипта?

[skazkin]

Там же написано почему)

[egoholic]

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

[developer]

помоему проблема решается установкой кеширующего сервера.

[alexbig]

я бы автору медаль за подробный разбор дал. спасибо.
p.s. давно перешёл на nginx + apache, ессно с gzip кто поддерживает.

[devaka]

Я может где-то что-то упустил, но какая версия PHP использовалась? Какой Apache и тестировалось ли это дело из коммандной строки?

[gnomeby]

Проблема при взаимодействии с веб-сервером. Версии окружения уже не важны. Важно только их настройка, но об этом подробнее в статье и в коментариях.