Уже есть 2 хороших ответа, но, возможно, самый важный вопрос из реальной жизни еще не упомянут.
Во-первых, OP может захотеть прочитать 2 предыдущих ответа и этот небольшой пост в блоге, чтобы понять, что такое keepalive. (Автор не уточняет, как TCPI / IP становится «быстрее», чем дольше открыто соединение. Это правда, более длительные соединения выигрывают от масштабирования IP-окна , но эффект не значителен, если файлы не большой, или продукт с задержкой полосы необычно большой.)
Большой аргумент против HTTP Keepalive при использовании Apache заключается в том, что он блокирует процессы Apache. Т.е. клиент, использующий пакеты keepalive, не позволит «своему» процессу Apache обслуживать других клиентов, пока клиент не закроет соединение или не истечет время ожидания. За тот же промежуток времени этот экземпляр Apache мог обслуживать множество других соединений.
В настоящее время очень распространенной конфигурацией Apache является Prefork MPM, интерпретатор PHP / Perl / Python и код приложения на указанном языке. В этом случае каждый процесс Apache является «тяжелым» в том смысле, что он занимает несколько мегабайт оперативной памяти (Apache связан с интерпретатором и кодом приложения). Это, вместе с блокировкой каждого экземпляра Apache keepalive, неэффективно.
Обычный обходной путь - это использование 2 серверов Apache (как на одном физическом сервере, так и на 2 серверах при необходимости) с разными конфигурациями:
- один «тяжелый» с mod_php (или любым другим используемым языком программирования) для динамического контента, с отключенной поддержкой активности .
- один «легкий» с минимальным набором модулей для обслуживания статического контента (image, css, js и т. д.), с поддержкой активности .
Затем вы можете расширить это разделение динамического и статического содержимого при необходимости , например:
- использование управляемого событиями сервера для статического контента, такого как nginx .
- использование CDN для статического контента (может сделать все обслуживание статического контента для вас)
- реализация кеширования статического и / или динамического контента
Другой подход, касающийся предотвращения блокировки Apache, заключается в использовании балансировщика нагрузки с более умной обработкой соединений, такой как Perlbal .
.. и многое другое. :-)
Keepalive могут быть хорошими в некоторых случаях, они могут быть очень плохими в других. Они сокращают время и усилия по созданию нового соединения, но связывают ресурсы сервера на время тайм-аута поддержки активности. Примеры:
Как видите, KeepAliveTimeout также сыграет большую роль в оптимизации производительности вашего сервера.
Посмотрите на вашу модель использования и решите сами.
источник
Вы должны обязательно использовать KeepAlive On.
Видеть:
http://httpd.apache.org/docs/2.0/mod/core.html#keepalive
Таким образом, одно TCP-соединение будет повторно использоваться браузером для отправки нескольких запросов. Обычно веб-сайт имеет много компонентов (HTML-страница, код JavaScript, изображения). Пока эти ресурсы находятся в одном домене и, следовательно, могут обслуживаться одним и тем же сервером, соединение KeepAlive значительно повышает производительность, поскольку браузеру не нужно устанавливать новое TCP-соединение.
Браузер обычно открывает около 3 параллельных подключений к домену. Допустим, у вас есть 18 объектов на вашем сайте. Браузер откроет 3 соединения и загрузит 6 объектов в каждом соединении - используя режим KeepAlive. Без KeepAlive пришлось бы открывать 18 TCP-соединений, что очень медленно.
Большинство или все современные браузеры совместимы с HTTP / 1.1, поэтому это должно сработать.
Некоторые прокси-серверы HTTP, такие как Squid, не совместимы с HTTP / 1.1, но они все равно запрашивают использование соединения KeepAlive.
источник