Назад | Перейти на главную страницу

Стоит ли активировать keepAlive в Apache2?

В любой установке по умолчанию Apache 2 поставляется с выключенным keepAlive, но при просмотре другого сервера модуль keepAlive был включен.

Итак, как мне узнать, подходит ли мне keepAlive? Где я могу найти хорошие примеры того, как это настроить?

Уже есть 2 хороших ответа, но, возможно, самая важная реальная проблема еще не упоминается.

Во-первых, OP может захотеть прочитать 2 предыдущих ответа и это небольшое сообщение в блоге чтобы понять, что такое пакеты поддержки активности. (Автор не уточняет, что TCPI / IP становится тем быстрее, чем дольше открыто соединение. Это правда, что более длительные соединения выигрывают от Масштабирование IP-окна, но эффект незначителен, если файлы не имеют большого размера или продукт с задержкой полосы пропускания необычно велик.)

Большой аргумент против HTTP Keepalive при использовании Apache в том, что он блокирует процессы Apache. Т.е. клиент, использующий пакеты Keepalive, не позволит «своему» процессу Apache обслуживать других клиентов, пока клиент не закроет соединение или не истечет время ожидания. За то же время этот экземпляр Apache мог обслуживать множество других подключений.

Теперь очень распространенной конфигурацией Apache является Prefork MPM интерпретатор PHP / Perl / Python и код приложения на указанном языке. В этом случае каждый процесс Apache «тяжелый» в том смысле, что он занимает несколько мегабайт оперативной памяти (Apache связан с кодом интерпретатора и приложения). Это, вместе с блокировкой каждого экземпляра поддержки активности Apache, неэффективно.

Обычный обходной путь - использовать 2 сервера Apache (оба на одном физическом сервере или на 2 серверах, если необходимо) с разными конфигурациями:

  • один "тяжелый" с mod_php (или любым другим языком программирования) для динамического контента, с Keepalives выключен.
  • один «легкий» с минимальным набором модулей для обслуживания статического контента (изображения, CSS, js и т. д.), с Keepalive на.

Затем вы можете расширить это разделение динамического и статического контента. при необходимости, например:

  • использование сервера, управляемого событиями, для статического контента, такого как nginx.
  • использование CDN для статического контента (может обслуживать весь статический контент за вас)
  • реализация кеширования статического и / или динамического контента

Другой подход, позволяющий избежать блокировки Apache заключается в использовании балансировщика нагрузки с более умной обработкой соединений, например Perlbal.

.. и многое другое. :-)

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

  • Страницы с множеством мелких объектов, клиенты на коммутируемом соединении - поддержка активности должна быть включена.
  • Страницы с несколькими большими объектами - поддержка активности не будет преимуществом.
  • Сервер с очень большим количеством уникальных посетителей - поддержка активности должна быть отключена (в противном случае сокеты и потоки будут сидеть в памяти в ожидании тайм-аута поддержки активности и не обслуживать новых клиентов).

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

Посмотрите на свою схему использования и решите сами.

Вам обязательно стоит использовать KeepAlive On.

Видеть:

http://httpd.apache.org/docs/2.0/mod/core.html#keepalive

Таким образом, одно TCP-соединение будет повторно использоваться браузером для отправки нескольких запросов. Обычно веб-сайт состоит из множества компонентов (HTML-страница, код javascript, изображения). Пока эти ресурсы находятся в одном домене и, следовательно, могут обслуживаться одним и тем же сервером, соединение KeepAlive дает огромный прирост производительности, поскольку браузеру не нужно устанавливать новое TCP-соединение.

Браузер обычно открывает около трех параллельных подключений к домену. Допустим, у вас на сайте 18 объектов. Браузер открывал 3 соединения и загружал по 6 объектов в каждое соединение - используя режим KeepAlive. Без KeepAlive ему пришлось бы открыть 18 TCP-соединений, что очень медленно.

Большинство или все современные браузеры совместимы с HTTP / 1.1, так что это должно работать.

Некоторые прокси-серверы HTTP, такие как Squid, не совместимы с HTTP / 1.1, но они все равно запрашивают использование соединения KeepAlive.