Если в этом смысле, то в принципе да, проблему неэффективного использования ресурсов это решает. Правда в таком случае придется потратить веремя на всю эту чистку памяти и проверку, да и все же всё вы не вычистите. Проще передать это всё из PHP во внешний по отношению к нему буфер, а его (PHP) благополучно освободить.
Почему не удобно в разработке? При разработке храним всё форматированным, со всеми отступами для удобства. А при выставлении на продакшн настраиваем сжатие всего и вся. Не вижу проблемы.
Как насчет того, чтобы проверять заголовки, которые пришли клиента? Если клиент говорит, что скушает gzip — кормить gzp'ом, отказался от gzip'а, но сказал, что ест deflate, то deflate'ом :)
«apache все максимально быстро сбросит на nginx»
Ха. И еще раз ха.
Угадайте, где теперь буфер? Правильно, на nginx. Если такой же буфер выделить для самого PHP, то будет то же самое. Единственное, что PHP сможет полностью закрыться, а не оставаться в фазе закрытия, что позволит сэкономить еще немного памяти.
Если же буфер для nginx поставить маленький, то вы вернетесь к той же проблеме. Проблема медленного клиента не может быть решена выбором реализации отдачи контента.
PS: Хотя конечно nginx для непосредственной отдачи намного лучше апача в отношении использования ресурсов.
Нет, там дополнительная задержка совсем незначительна. Проявиться это может только тогда, когда у нас не только отдается много, но это «много» еще и очень медленно генерируется. А это уже скорее вопрос оптимизации скриптов.
Проблема в том, что пока не закончил работать PHP — под него зарезервировано значительное количество памяти. А на серверах именно память и загрузка процессоров — основной ресурс.
Если у вас, страница влазит в буфер — то разницы не будет: отдавать сразу или одним куском в конце. Точнее будет разница на время генерации страницы. Если страница в буфер не влезла, то в PHP останавливается, пока не будет отдано всё, что до этого нагенерилось. В любом из двух случаев накопление контента и отдача его одним куском ситуацию не улучшит. Но и не ухудшит сильно.
Основной метод решения проблемы — минимизация передаваемого объема. Так что Tidy и Gzip — наше всё :)
Кстати, в комментариях к статье, на которую ссылается автор, тоже высказывают непонимание относительно того, при чем тут этот алгоритм. Кстати, там есть отсылка к его спецификации.
Не понимаю нападок на «Nagle's algorithm». Очень уж отдаленно он связан с проблемой. Его суть сводится лишь к тому, что не посылаются пакеты слишком малого размера, а чуть чуть придерживаются, пока не наберется большой пакет. И всё.
У вас же проблема прямо-таки противоположная — вы хотите сразу послать много больших пакетов, да вот только клиент их не может принять. А пока он пакеты не принял, вам их нужно где-то хранить. Где? Правильно в буфере вывода PHP. Да вот только буфер тоже не резиновый (по умолчанию). Как следствие — приходится полностью останавливать PHP, чтобы он нам не переполнял этот буфер. Последствия вы уже описали.
Проблема вызвана не использованием накопления пакетов («Nagle's algorithm»), а тем что мы не можем мгновенно перебросить клиенту всё, что нагенерировал наш PHP код. И эта проблема как была так и останется. Всё что можно с ней разумного сделать — выставить размер буфера в соответствие с размером страниц сайта.
PS: Выставлять неограниченный буфер — на самом деле довольно плохая идея. Буфер должен быть большим, но не резиновым.
Вместе с инвайтом в базе хранить id пользователя, который создал этот инвайт. При регистрации пользователя по инвайту сохранять в запись пользователя тот id из инвайта. То есть для каждого пользователя хранить информацию о том, кто его привел.
Это позволяет отслеживать кто кого пригласил. Так как в профиле есть еще дата регистрации и географическая привязка, то можно получть много интересных данных. Например, отслеживать географическое распространение в зависимости от времени с учетом связей, активность распространения в зависимости от региона и т.д.
Ха. И еще раз ха.
Угадайте, где теперь буфер? Правильно, на nginx. Если такой же буфер выделить для самого PHP, то будет то же самое. Единственное, что PHP сможет полностью закрыться, а не оставаться в фазе закрытия, что позволит сэкономить еще немного памяти.
Если же буфер для nginx поставить маленький, то вы вернетесь к той же проблеме. Проблема медленного клиента не может быть решена выбором реализации отдачи контента.
PS: Хотя конечно nginx для непосредственной отдачи намного лучше апача в отношении использования ресурсов.
Если у вас, страница влазит в буфер — то разницы не будет: отдавать сразу или одним куском в конце. Точнее будет разница на время генерации страницы. Если страница в буфер не влезла, то в PHP останавливается, пока не будет отдано всё, что до этого нагенерилось. В любом из двух случаев накопление контента и отдача его одним куском ситуацию не улучшит. Но и не ухудшит сильно.
Основной метод решения проблемы — минимизация передаваемого объема. Так что Tidy и Gzip — наше всё :)
У вас же проблема прямо-таки противоположная — вы хотите сразу послать много больших пакетов, да вот только клиент их не может принять. А пока он пакеты не принял, вам их нужно где-то хранить. Где? Правильно в буфере вывода PHP. Да вот только буфер тоже не резиновый (по умолчанию). Как следствие — приходится полностью останавливать PHP, чтобы он нам не переполнял этот буфер. Последствия вы уже описали.
Проблема вызвана не использованием накопления пакетов («Nagle's algorithm»), а тем что мы не можем мгновенно перебросить клиенту всё, что нагенерировал наш PHP код. И эта проблема как была так и останется. Всё что можно с ней разумного сделать — выставить размер буфера в соответствие с размером страниц сайта.
PS: Выставлять неограниченный буфер — на самом деле довольно плохая идея. Буфер должен быть большим, но не резиновым.
Это позволяет отслеживать кто кого пригласил. Так как в профиле есть еще дата регистрации и географическая привязка, то можно получть много интересных данных. Например, отслеживать географическое распространение в зависимости от времени с учетом связей, активность распространения в зависимости от региона и т.д.