Я думаю, что вы сбились с толку от буферизации ответа лака. Предположим, что самый быстрый ваш сервер может ответить 100-страничной страницей для данного запроса - 10 секунд, отправляя по 10 тысяч в секунду. Без лака в вашем стеке клиентское соединение туннелируется непосредственно на задний конец, и браузер начинает получать данные за 1 секунду (первые 10k и начинает анализировать, отображать, следовать за <link> тегами и т. Д.).
С лаком в вашем стеке он ожидает, что задний конец отправит всю страницу перед отправкой первого байта клиенту. Таким образом, клиент должен ждать 10 секунд, пока он не сможет начать рендеринг страницы, следуя <link> тегам и т. Д. Верьте или нет, это хорошо для двух основных причин. Во-первых, если этот ответ кэшируемый, следующий клиент не должен ждать 10 секунд, чтобы задний конец сгенерировал ответ, лак будет обслуживать его довольно быстро (мс, а не s). Если ваш рейтинг попадания высок, и вы должны его оптимизировать, первоначальная стоимость ожидания первого байта ответа платит много дивидендов в будущих хитах кэша.Двое, скажем, мобильный телефон по пятнистому сотовому сигналу запрашивает эту же страницу на 100 тыс. Страниц, но он не может загрузить страницу так быстро, как может ее создать бэкенд, ей нужна полная минута, чтобы получить страницу 100 тыс. Страниц. При использовании лака apache не должен тратить время на соединение и нить на целую минуту (в основном, простаивайте, заметьте), пока он медленно передает данные клиенту. Он отправляет данные так быстро, как можно лакировать, а затем переходит к следующему запросу, а лак медленно посылает данные клиенту.
Для запросов, которые, как известно, не подлежат кешированию, вы можете настроить лак через VCL, если хотите, return (pipe), что не приведет к буферизации ответа. Он отправит данные непосредственно с вашего конца клиенту, как только он его получит. Но в канале default.vcl не используется.