Я читал на сайте, что еще одним преимуществом наличия Lighttpd перед Apache является меньшее количество дочерних процессов. Lighttpd будет обрабатывать keep-alive и клиентские запросы, в то время как дочерние процессы Apache будут быстрее обслуживать динамические страницы из-за очень низкой задержки связи между Lighttpd и Apache. Я пытаюсь найти ссылку, но мне трудно.
Учитывая, что у меня уже есть выделенный сервер Lighttpd для моего статического содержимого (img, vid, css, js, html и т. Д.) И еще один выделенный сервер Apache для моих динамических страниц (php), я хотел бы реализовать этот метод, если он действительно имеет некоторый прирост производительности.
1) Ставил ли кто-нибудь Lighttpd перед Apache с той же целью, как описано выше?
2) Действительно ли на этом есть прирост производительности? Сколько?
3) А как насчет накладных расходов Lighttpd на обработку запроса к Apache, действительно ли это того стоит?
Спасибо!
Раньше я был в той же ситуации, подавая в суд на lighttpd рядом с apache) за снижение нагрузки на apache.
Статический контент лучше обслуживать с помощью легкого веб-сервера, поскольку он требует меньше ресурсов. Также следует упомянуть, что PHP требует, чтобы apache работал в предварительно разветвленном режиме, что отключает эффективную работу apache. Вы можете распределить нагрузку на два, по-разному настроенных веб-серверах, каждый из которых обрабатывает трафик, на котором он лучше всего работает.
Некоторые примечания по реализации:
У вас есть три варианта:
Первый быстрее, второй требует меньше настроек, третий похож на мула.
Я бы не рассматривал третий вариант на вашем месте, поскольку он сопровождается кошмаром конфигурации, а также, если вы неправильно сконфигурируете что-то на первом веб-сервере, ничего не будет работать, и будет труднее определить, в чем проблема.
Раньше мне нужно было срочно найти решение, поэтому я выбрал вариант 2 и использовал обратный прокси-сервер под названием фунт для сегментации запросов по статическому / динамическому содержимому и распределения нагрузки на два разных веб-сервера.
Хотя он работает, он требует активного мониторинга содержимого http, что снижает производительность (работает дополнительный демон).
С вариантом 2 вы можете повысить производительность за счет использования дополнительного IP-адреса для статического контента (static.domain.org) и заставить клиентов обращаться к этому static.domain.org за контентом. По-прежнему потребуется обратный прокси, но прокси не должен проверять заголовок Host: ни в одном из запросов, поэтому он будет быстрее.
вот фрагмент конфигурации фунта для справки:
ListenHTTP
Address 195.175.71.17
Port 80
Client 30
RewriteLocation 2
Service
HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
URL "^/static/content"
BackEnd
Address 127.0.0.1
Port 81
TimeOut 300
End
End
Service
HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
BackEnd
Address 127.0.0.1
Port 80
TimeOut 300
End
End
ListenHTTP
Тем не менее, вы должны рассматривать обратный прокси Varnish вместо lighty (или перед ним) в качестве интерфейса. Это очень быстро и эффективно. Это особенно интересно для кеширования динамических страниц (или фрагментов страниц с использованием ESI), так как это помогает снизить внутреннюю нагрузку и поглотить всплески трафика.
И, возможно, использовать nginx (с PHP-FCGI) в качестве бэкэнда вместо Apache (хотя это более сложная задача, чем добавление внешнего интерфейса Varnish) (nginx также может использоваться в качестве внешнего интерфейса, но не так хорош, как выделенный обратный прокси, например Лак). Отказ от ответственности: у меня нет опыта работы с nginx;)