Совместимость — понятие условное. Теже ядерные модули ломаются иногда и при накатывании patch cluster внутри одной major версии. Судя по радости от snapshot'ов, package manager находится по прежнему в зачаточном состоянии?
удобно контролировать работу внештатников или каких-нибудь внешних разработчиков — они работают в своем репозитарии, выдавая коммиты на проверку разрабочикам проекта. При одобрении изменения помещаются в центральный репозаторий.
При этом:
а) Видна история коммитов внешних людей — видно кто/что/когда и зачем делал
б) Видно кто и когда поместил эти изменения в проект
в) Внешние разработчики могут легко перетягивать (merge'ить) к себе в рабочий репозитарий изменения в центральном хранилище, сохраняя актуальность своей копии проекта.
По большому счету да. Терминальные приложения сейчас составляют малый процент траффика, а программам передающим данные большими блоками nagle-алгоритм только мешает. Хотя раз держат его включенным по умолчанию в ОС значит чем-то это оправдано (надеюсь, не только историческими соображениями ;-)
Проблема которую вы на самом деле пытаетесь решить вот в чем: пока пользователь скачивает страничку с сервера, он занимает его ресурсы. Если вы его «кормите» выводом скрипта, то без буферизации скорость работы скрипта будет ограничена тем, с какой скоростью пользователь готов «есть» генерируемые им данные.
Буферизация позволяет освободить дорогие ресурсы сервера (соединения к БД, треды выполняющие PHP-запросы и т.п.) за счет более дешевых ресурсов вроде оперативной памяти. Благодаря буферизации скорость исполнения скрипта не ограничивается скоростью клиента. При этом буферизацию лучше выполнять не средствами PHP, а в веб-сервере nginx/lighttpd. За счет своей архитектуры они способны «кормить» буферизованными данными тысячи медленных пользователей практически не занимая системных ресурсов в момент ожидания готовности пользователя (главное чтобы памяти хватило). Apache подходит хуже т.к. на одного пользователя занимает тред/процесс вместе с довольно дорогим контекстом.
Так что либо надо жертвовать памятью, либо отказываться от скриптов которые генерируют слишком большие страницы.
Nagle-алгоритм был придуман для программ вроде telnet, в которых нажатие клавиши пользователем приводит к вызову системного вызова write(), приводящего к отсылке пакета с данными. Чтобы в сеть не летело много мелких пакетов, nagle-алгоритм немного притормаживает передачу дабы собрать идущие подряд вызовы write() в один пакет.
Приложения которые умеют нормально буферизовать вывод (а не дергают write на каждый выводимый байт) выключают nagle алгоритм путем выставления опции сокета TCP_NODELAY. При этом каждый write приводит немедленной отсылке пакета без задержек. В apache такая опция на сокете стоит практически от рождения.
Однако единственный побочный эффект, который может вызвать включенный Nagle — увеличение времени отклика сервера. К вашей проблеме это имеет весьма отдаленное отношение.
При этом:
а) Видна история коммитов внешних людей — видно кто/что/когда и зачем делал
б) Видно кто и когда поместил эти изменения в проект
в) Внешние разработчики могут легко перетягивать (merge'ить) к себе в рабочий репозитарий изменения в центральном хранилище, сохраняя актуальность своей копии проекта.
Буферизация позволяет освободить дорогие ресурсы сервера (соединения к БД, треды выполняющие PHP-запросы и т.п.) за счет более дешевых ресурсов вроде оперативной памяти. Благодаря буферизации скорость исполнения скрипта не ограничивается скоростью клиента. При этом буферизацию лучше выполнять не средствами PHP, а в веб-сервере nginx/lighttpd. За счет своей архитектуры они способны «кормить» буферизованными данными тысячи медленных пользователей практически не занимая системных ресурсов в момент ожидания готовности пользователя (главное чтобы памяти хватило). Apache подходит хуже т.к. на одного пользователя занимает тред/процесс вместе с довольно дорогим контекстом.
Так что либо надо жертвовать памятью, либо отказываться от скриптов которые генерируют слишком большие страницы.
Приложения которые умеют нормально буферизовать вывод (а не дергают write на каждый выводимый байт) выключают nagle алгоритм путем выставления опции сокета TCP_NODELAY. При этом каждый write приводит немедленной отсылке пакета без задержек. В apache такая опция на сокете стоит практически от рождения.
Однако единственный побочный эффект, который может вызвать включенный Nagle — увеличение времени отклика сервера. К вашей проблеме это имеет весьма отдаленное отношение.