Вопросы Теги

Другое преимущество Lighttpd перед Apache

Это действительно идет в, зависит от точно, что Вы после делаете. Какой путь передается исходному запросу? Это всегда/audio/some_id/other_stuff? В чем другая конфигурация там для путей с "аудио"? Для запроса формы:

http://www.example.com/audio/some_id/other_stuff

Вы, вероятно, захотите RewriteRule:

ReWriteRule ^/audio/(.*)/.*$ /audio.php?id=$1

Я думаю.*? не делают то, что Вы хотите. Дайте этому водоворот и посмотрите то, что он делает. Можно также найти справочник регулярного выражения Perl полезным.

3
задан 12 August 2010 в 13:31
2 ответа
  1. У нас был lighty обслуживание статического содержания и передача динамических запросов к Apache на том же сервере, но слушанию на другом порте
  2. "вперед апачу для динамического" не был сделан в целях производительности, но только иметь единственный сервер от точки клиента, служа всему. Однако, если можно избежать избыточных соединений с Apache, это - хорошая дополнительная льгота. Больше соединений = больше процессов = больше памяти (особенно с mod_php). Так, никакие числа, извините.
  3. издержки казались negligle по сравнению с пожирателем ресурсов, который является Apache

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

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

2
ответ дан 3 December 2019 в 06:48

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

Лучше служить статическому содержанию с легким веб-сервером, поскольку требуется меньше ресурсов. Также должны упомянуть, который PHP требует, чтобы апач выполнил в предразветвленном режиме, который отключает апача от выполнения эффективно. Можно распределить загрузку в два, по-другому настроить веб-серверы, каждый обрабатывающий трафик, в котором это является лучшим.

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

У Вас есть три опции:

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

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

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

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

Хотя это работает, это требует активно контроля http содержания, которое берет его сбор на производительности (дополнительный демон, работающий).

С опцией 2 можно получить лучшую производительность с использованием дополнительного IP для статического содержания (static.domain.org) и добраться, клиенты обращаются к этому static.domain.org для содержания. Это все еще потребует обратного прокси, но прокси не должен проверять Хост: заголовок в любом из запросов, таким образом, это будет более быстро.

вот отрывок конфигурации фунта для Вашей ссылки:

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
ответ дан 3 December 2019 в 06:48

Теги

Похожие вопросы