Для начала хочу заметить что главная причина использование схемы фронтенд-бэкенд - эффективное использование ресурсов. Актуально это прежде всего для веб-порталов с большим количеством посетителей. Если на вашем сервере меньше 10 http-запросов в секунду, то можно продолжать использовать apache без фронтенда и не тратить силы и время на построение схемы фронтенд-бэкенд.
Q: а нафиг нужен nginx, есть же апач?
A: nginx и apache это совершенно разные сервера для разных задач, и сравнивать их некорректно. nginx предназначен для раздачи статики и использования в качестве фронтендов. Apache при этом можно использовать в качестве бэкенда для генерации динамического контента.
Если клиентов пускать напрямую к бэкенду (например apache+mod_perl) без фронтенда, то серверов под бэкенды потребуется в несколько раз больше.
Q: Почему nginx работает эффективнее чем apache при раздаче статического контента.
A: Для того, чтобы было понятно о чем пойдет речь ниже нужно понимать какие модели сетевых серверов бывают и чем они отличаются. Читать тут: RU.UNIX.PROG FAQ - приложение 1: как писать сервера
A:
1. apache 1.3 использует preforked модель (чем плох apache2 отдельная тема), а nginx для обработки соединений использует FSM, причем для обработки соединений могут использоваться очень эффективные методы kqueue (BSD), epoll (Linux).
2. Для отдачи файлов используется sendfile()
3. Автор nginx уделяет большое значение оптимизации. На обработку одного http-запроса делается заметно меньше системных вызовов, чем в других серверах (для примера сравните truss nginx и thttpd, при раздаче статических файлов - thttpd делает больше вызовов, хотя в остальном похож). Надеюсь не надо объяснять что каждый системный вызов это переключение контекста и чем их меньше, тем лучше.
Q: Зачем нужно разделение на фронтенд-бэкенд, почему нельзя запросы к динамическим страницам сразу раздавать apache+mod_perl (или что там используется для генерации динамики)
A: Проще объяснить на примере:
Представим себе такую ситуацию - у нас 1000 клиентов, которые медленно
забирают странички.
В случае апаче - мы имеем 1000 процессов httpd и кучу переключений контекста с этим связанных. Плюс каждый httpd кушает кучу памяти из за того, что обрабатывает php/perl скрипты, а все вместе 1000 процессов будут кушать нереально большое количество памяти.
И при этом каждый процесс будет заниматься 0.1 секунду генерацией ответа, а 10 секунд тем, что будет отдавать ответ клиенту. В итоге мы имеем очень низкий КПД и большую нагрузку на сервер.
Теперь поставим прослойку в виде nginx перед апачем. Допустим у нас есть один рабочий процесс, для проксирования этого вполне хватит.
Приходит запрос клиента. nginx сначала его дожидается (это тоже может быть долго), потом максимально быстро передает запрос бэкенду (апачу) и максимально быстро читает ответ. В итоге апач на каждый запрос занят не 10 секунд, а 0.1 секунду и процессов httpd у нас будет не 1000 а 10.
Ответ при этом буферезируется в nginx но объем ответа обычно в несколько раз меньше чем объем процесса на бэкенде (httpd+perl,php или даже java), который этот ответ создал, поэтому память будет очень заметно экономится.
Разумеется это не нужно если все клиенты подключены каналом 100 Мбит или быстрее, но на практике это не встречается. Обычно у клиентов достаточно медленные каналы. Если не dial-up, то в лучшем случае 128 - 256 Кбит. А при такой скорость ответ веб-сервером генерируется быстрее чем его успевает забрать клиент.
Может возникнуть вопрос почему nginx может использовать один процесс для обслуживания тысяч клиентских подключений, а бэкенд (сервер которые генерит динамику, например apache+mod_perl) не может. nginx для обработки клиентских соединений использует FSM (конечный автомат) - это очень эффективная модель, но она имеет ряд ограничений. Нельзя использовать системные/библиотечные вызовы которые надолго блокируются или надолго требуют много CPU (т. е. любые операции которые по разным причинам требуют много времени). Генерация динамического контента таким образом не может быть выполнена с использованием FSM. Поэтому для этого используется Prefork или потоки. apache13 использует prefork - на каждую клиентскую коннекцию по процессу, а процесс как говорилось выше это тяжелый объект. В apache2 можно использовать треды но у них свои проблемы. В первую очередь php/perl в тредовом режиме работают очень ненадежно, если вообще работают...
Q: Почему для проксирования запросов на бэкенд стоит использовать nginx, а не squid
A:
1. nginx это не только proxy, он может часть запросов (на статику) обслуживать сам, а часть проксировать. Причем те uri, которые (не)нужно проксировать могут заданы по regexp.
2. nginx имеет большие возможностей по конфигурированию, характерные для веб-серверов, но отсутствующие в обычных proxy-серверах.
3. nginx использует эффективную FSM и хорошо оптимизирован (в плане экономии системных вызовов).
