☰

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

tag-icon • tag-icon apache-2.2 performance lighttpd latency
Еще одно преимущество 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, действительно ли это того стоит?

Спасибо!

решение1

  1. У нас была легкая обработка статического контента и пересылка динамических запросов в Apache на том же сервере, но прослушивание на другом порту.
  2. "forward to apache for dynamic" не было сделано для повышения производительности, а просто для того, чтобы иметь единый сервер с точки зрения клиента, обслуживающий все. Однако, если вы можете избежать лишних подключений к Apache, это хороший побочный эффект. Больше подключений = больше процессов = больше памяти (особенно с mod_php). Так что, извините, никаких цифр.
  3. накладные расходы кажутся ничтожными по сравнению с тем, что представляет собой Apache

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

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

решение2

Я раньше был в такой же ситуации, подавая в суд на lighttpd вместе с apache) для снижения нагрузки на apache.

Лучше обслуживать статический контент с помощью легкого веб-сервера, так как он требует меньше ресурсов. Также следует упомянуть, что PHP требует, чтобы Apache работал в режиме pre-fork, что не позволяет 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

Связанный контент