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

Еще одно преимущество Lighttpd перед Apache

Я читал на сайте, что еще одним преимуществом наличия 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. Вы можете распределить нагрузку на два, по-разному настроенных веб-серверах, каждый из которых обрабатывает трафик, на котором он лучше всего работает.

Некоторые примечания по реализации:

У вас есть три варианта:

  1. изменить код и сегментировать трафик на уровне IP
  2. не изменяйте свой код и не сегментируйте трафик на уровне приложения (http)
  3. заставить один из веб-серверов передавать запросы, поступающие на другой веб-сервер, для фактического обслуживания

Первый быстрее, второй требует меньше настроек, третий похож на мула.

Я бы не рассматривал третий вариант на вашем месте, поскольку он сопровождается кошмаром конфигурации, а также, если вы неправильно сконфигурируете что-то на первом веб-сервере, ничего не будет работать, и будет труднее определить, в чем проблема.

Раньше мне нужно было срочно найти решение, поэтому я выбрал вариант 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 
  1. У нас было легкое обслуживание статического контента и пересылка динамических запросов в Apache на том же сервере, но прослушивание на другом порту.
  2. «переадресация на apache для динамического» была сделана не с целью повышения производительности, а просто для того, чтобы иметь один сервер с точки зрения клиента, обслуживающий все. Однако, если вы можете избежать лишних подключений к Apache, это будет хорошим побочным преимуществом. Больше соединений = больше процессов = больше памяти (особенно с mod_php). Итак, нет цифр, извините.
  3. накладные расходы казались незначительными по сравнению с свиньей, которой является Apache

Тем не менее, вы должны рассматривать обратный прокси Varnish вместо lighty (или перед ним) в качестве интерфейса. Это очень быстро и эффективно. Это особенно интересно для кеширования динамических страниц (или фрагментов страниц с использованием ESI), так как это помогает снизить внутреннюю нагрузку и поглотить всплески трафика.

И, возможно, использовать nginx (с PHP-FCGI) в качестве бэкэнда вместо Apache (хотя это более сложная задача, чем добавление внешнего интерфейса Varnish) (nginx также может использоваться в качестве внешнего интерфейса, но не так хорош, как выделенный обратный прокси, например Лак). Отказ от ответственности: у меня нет опыта работы с nginx;)