Я должен активировать проверку активности в Apache2?
- жемчуг
- склонный - добираются
- du
- энергия
- наверх
Уже существует 2 хороших ответа, но, возможно, самая важная реальная проблема еще не упоминается.
Прежде всего OP мог бы хотеть прочитать 2 предыдущих ответа и это небольшое сообщение в блоге для понимания, каковы сообщения проверки активности. (Автор не уточняет часть о получении TCPI/IP "быстрее" дольше, соединение открыто. Это - истинное, дольше длительное преимущество соединений от масштабирования окна IP, но эффект не является значительным, если файлы не являются большими, или продукт bandwith-задержки является необычно большим.)
Большой спор против Проверки активности HTTP при использовании Apache - то, что это блокирует процессы Apache. Т.е. клиент, использующий сообщения проверки активности, будет препятствовать тому, чтобы 'его' процесс Apache обслуживал любые другие клиенты, пока клиент не закроет соединение, или тайм-аут достигнут. В том же промежутке времени этот экземпляр Apache, возможно, служил многим другим соединениям.
Теперь, очень общая конфигурация Apache является Предварительным ветвлением MPM и PHP / Perl / интерпретатор Python и код приложения на упомянутом языке. В этом случае каждый процесс Apache "тяжел" в том смысле, что он занимает несколько мегабайтов RAM (Apache, связанный с интерпретатором и кодом приложения). Это, вместе с блокированием каждого keepalive'd экземпляра Apache, неэффективно.
Общее обходное решение должно использовать 2 сервера Apache (оба на том же физическом сервере, или на 2 серверах, по мере необходимости) с различными конфигурациями:
- одно "нагруженное" mod_php (или независимо от того, что язык программирования используется) для динамического контента, с сообщениями проверки активности прочь.
- один "легкий вес" с минимальным набором модулей, для обслуживания статического содержания (изображение, CSS, js и т.д.), с сообщениями проверки активности на.
Можно затем подробно остановиться на этом разделении динамического и статического содержания при необходимости, например:
- с помощью событийно-ориентированного сервера для статического содержания, такого как nginx.
- использование CDN для статического содержания (мог сделать все помехи, довольные обслуживание для Вас),
- реализация кэширования статического и/или динамического контента
Другой подход относительно старается не блокироваться, Apache должен использовать подсистему балансировки нагрузки с более умной обработкой соединения, такой как Perlbal.
.. и намного больше.:-)
Сообщения проверки активности могут быть хорошими в некоторых случаях, они могут быть очень плохими в других. Они уменьшают время и усилие по установке нового соединения, но они связывают ресурсы сервера на время тайм-аута проверки активности. Примеры:
- Страницы со многими маленькими объектами, клиентами на коммутируемом доступе - проверка активности должна идти.
- Страницы с несколькими большими объектами - проверка активности не будут преимуществом.
- Сервер с очень высоким количеством уникальных посетителей - проверка активности должна быть выключена (иначе, сокеты и потоки будут находиться в памяти, ожидающей тайм-аута проверки активности и не служащей новым клиентам).
Как Вы видите, KeepAliveTimeout будет также играть большую роль в оптимизации Вашей производительности сервера.
Посмотрите на свой шаблон использования и решите для себя.
Необходимо определенно использовать KeepAlive На.
См.:
http://httpd.apache.org/docs/2.0/mod/core.html#keepalive
Тем путем единственное соединение TCP будет снова использовано браузером для отправки нескольких запросов. Обычно веб-сайт имеет много компонентов (страница HTML, код JavaScript, изображения). Пока эти ресурсы находятся в том же домене, поэтому может быть подан тем же сервером, соединение KeepAlive дает огромное повышение производительности, так как браузер не должен будет устанавливать новое соединение TCP.
Браузер обычно открывает приблизительно 3 параллельных соединения с доменом. Так скажем, у Вас есть 18 объектов в Вашем сайте. Браузер открыл бы 3 соединения, и он загрузит 6 объектов в каждом соединении - использование режима KeepAlive. Без KeepAlive это должно было бы открыть 18 TCP connections, который является очень медленным.
Большинство или все современные браузеры является HTTP/1.1, совместимым, таким образом, это должно просто работать.
Определенными Прокси HTTP как Сквид не является совместимый HTTP/1.1, но они запрашивают использование соединения KeepAlive так или иначе.