Концепция фронтального прокси Apache + Lighttpd

Question

Чтобы облегчить нагрузку на Apache, люди часто предлагают использовать Lighttpd для обслуживания статического контента.

например http://www.linux.com/feature/51673

В этой настройке Apache передает запросы на статический контент обратно в Lighttpd через mod_proxy, одновременно обслуживая динамические запросы.

Мой вопрос:как это снижает нагрузку на сервер?Поскольку у вас все еще есть процесс Apache, создаваемый для каждого поступающего запроса, как это положительно влияет на нагрузку?Насколько я вижу, размер процесса Apache, передающего свой запрос через Lighttpd, такой же большой, как если бы он обслуживал сам файл.

Answer 1

Запуск Lighttpd позади Apache для обслуживания статических файлов определенно кажется мне безумием.Apache все еще должен распаковать HTTP-пакеты и проанализировать запрос через свое дерево разбора, отправить прокси-запросы, а затем Lighttpd должен повторно распаковать, обратиться к файловой системе и отправить файлы обратно через Apache.Я никогда не слышал, чтобы кто-то использовал подобную установку в производстве.

Вы увидите, что люди используют легкий веб-сервер, например Нгинкс как внешний интерфейс сервер для обслуживания статических файлов и динамических URL-адресов прокси-сервера Apache.Или вы можете запустить Лак или Кальмар в качестве кеширующего интерфейса обратного прокси-сервера, чтобы все ваши статические файлы с высоким трафиком (т.изображения, CSS и т. д. и любые динамические страницы, для которых вы хотите отправлять кэшируемые заголовки), обслуживаются из-за нехватки памяти.

Apache также можно оптимизировать для обслуживания статических файлов — поэтому часто, когда я слышу, как люди жалуются на Apache, они действительно не знают, как его настроить.Они когда-либо использовали только префорк MPM (по сравнению с MPM).многопоточный или рабочий) и имеют все виды включенных модулей (обычно они запускаются из пакета Apache для кухонной раковины дистрибутива Linux, который собирает все как модули и по умолчанию включает 10-20 модулей или более).Настройте Apache, сначала отключив ненужные модули/глупые функции, такие как поддержка .htaccess (что заставляет Apache сканировать файловую систему при каждом запросе!).(Вы также можете запустить два экземпляра Apache, используя «легкий» Apache в качестве внешнего интерфейса, который обращается к «тяжелому» Apache для динамических запросов...возможно, ваш интерфейс является многопоточным, но ваш бэкэнд является префорком, потому что вам приходится запускать небезопасные для потоков внешние модули, такие как mod_php.)

Ре:

Поскольку у вас все еще есть процесс Apache, который породился за каждый запрос, который поступает, как это положительно влияет на нагрузку?Из того, что я вижу, размер процесса Apache, прокси, прокси, его запрос, через LightTPD, так же велик, как и если бы он обслуживал сам файл.

Если вы создаете процессы при каждом запросе, это означает, что вы используете prefork MPM.Имейте в виду, что когда ОС сообщает об использовании памяти для каждого из этих процессов, не вся эта память подключена, многие из этих процессов простаивают.И когда вы говорите о скорости, вас больше волнует анализ запроса и внутренние ветки кода для данного запроса (сколько обработки выполняет сервер?), чем использование памяти, сообщаемое ОС.

Например, если вы включите что-то вроде mod_php, то каждый из этих рабочих процессов мгновенно увеличится примерно на 20-40 МБ (в зависимости от того, что включено в вашем интерпретаторе PHP), но это не означает, что Apache использует эту память на статические запросы.Конечно, если вы оптимизируете свой сервер для максимального параллелизма с небольшими статическими файлами, то включение mod_php все равно будет очень плохим, вы не сможете разместить в оперативной памяти почти столько же процессов prefork.

Я, вероятно, мог бы придумать «кошмарную конфигурацию» для Apache, которая бы на самом деле это будет медленнее обслуживать статические файлы, чем пересылать эти запросы на серверную часть Lighttpd, но это потребует включения дорогостоящих функций, таких как .htaccess в Apache, которые отключены в Lighttpd, поэтому это было бы не совсем справедливо.

Answer 2

1. Если у тебя еще есть силы служить статический и динамический контент из та же машина (как они в вашем ссылочная статья do), то я действительно не вижу смысла в такой настройке.
2. Возможно, это уменьшит нагрузку на Apache, поскольку ему не нужно выполнять ввод-вывод на диск, но увеличит загрузку Lighttpd на та же самая машина и тем самым уменьшая доступная загрузка в Apache ...
3. Возможно, доступ к вводу-выводу Lighttpd проще, чем у Apache 1.3, но почему бы просто не перейти на Apache 2 или Lighttpd полностью?А если производительность действительно начнет падать, разместите статические файлы на другом компьютере (media.yourdomain.com).

Небольшое введение в то, как можно создать производительную настройку, можно найти здесь:Развертывание Джанго -> прокрутите до Scaling какая-то страница до конца

Answer 3

Я мало что знаю о внутренней работе Apache, но одно из объяснений, которое я видел, касается нехватки памяти.Короче говоря, Apache пытается сбалансировать память, используемую для кэширования и динамических страниц;но обычно в итоге получается слишком много кеша и слишком мало для приложений.Если разделить их на разные процессы, каждый из них будет оптимизирован под тип нагрузки.

В настоящее время я использую nginx как передняя часть.Он действительно быстрый и легкий и специально разработан как внешний прокси;но также обслуживает статические файлы.Фактически, поскольку он также может вызывать процессы FastCGI, вы можете избавиться от Apache и по-прежнему получать преимущества разделения процессов файлов и приложений.(и есть еще кое-что магия memcached это выглядит просто гениально)

(Да, Lighttpd также можно использовать в качестве интерфейса для Apache и/или FastCGI)

Answer 4

У вас нет процесса Apache, создаваемого для каждого запроса — статические файлы (изображения и тому подобное) извлекаются напрямую с помощью Lighttpd.

Answer 5

Используйте Apache MPM Worker fastcgi, это снизит использование памяти сервера.MPM Worker обслуживает статический контент лучше, чем Prefork, и почти на одном уровне с Lighttpd, когда дело касается статического контента.