Apache + nginx? Спасибо, есть lighttpd

Category: Прочее
Posted on: 15.04.2014 в 20:55 - 3 Comments - Visited 6563 times

И так, спустя много-много времени, наконец пишу эту статью. Советую почитать всё, не смотря на много букв. Если вам лень их читать, то лучше всего lighttp, ставьте его и не мучайте себя догадками "почему". Если интересно, давайте всё же уделите немного времени и почитайте статью

 

Apache

Это самый популярный сервер, очень гибкий, очень настраиваемый, НО... тут и кончаются все прелести и начинаются минусы. Если вы планируете строить сайт, на котором будут пастись сотни пользователей, придётся принять во внимание, что Apache очень плохо для этого подходит.

Apache бывает двух видов, prefork и worker. Если вы не в курсе таких тонкостей, то "обычный" Apache - это prefork модель, где каждый запрос обрабатывается отдельным процессом. При такой схеме каждый процесс Apache обрастает уникальными от других процессов буферами и использует довольно много памяти. Worker использует модель, где каждый запрос обрабатывается несколькими процессами, что существенно уменьшает аппетиты к оперативной памяти. НО (да-да, ;))... при такой конструкции становится невозможным использовать thread safe библиотеки, к примеру mod_php. Именно поэтому Apache worker почти не используется. Ещё стоить отметить, что если ваш Apache "атакуют" dial-up'еры или прочие модемщики и забьют все worker'ы, которые будут просто висеть и ничего не делать, то все остальные пользователи тоже будут получать ответы со скоростью модема.

Ко всем этим "прелестям" ещё добавим не очень хорошую реализацию буфера отдачи статического содержимого сайта, который точно также не стесняясь, поедает процессор и память и можно читать дальше...

 

nginx

Сейчас стало модно ставить сий nginx "перед" Apache как распределитель запросов и отдачи статического содержимого, такого как файлы изображений, стилей или скриптов. Nginx использует более совершенную технологию обработки запросов, и помогает неповоротливому Apache, чем только может. НО (ага :))... в данной связке nginx выступает как прокси между пользователем и Apache и создаёт дополнительный запрос к толстячку к уже существующему. Это не сколько лишняя память, как лишнее время. Кроме того nginx всегда тащится в хвосте со скрипом поддерживая или не поддерживая вообще, то что у конкурентов уже широко используется. Например до сих пор многие с нетерпением ждут, когда уже nginx начнёт поддерживать IPv6, до этого всё мечтали, когда он сможет работать с CGI скрипты, перестанет коверкать PATH_INFO и SCRIPT_NAME. В режиме прокси этот нехороший товарищ ещё не даёт отдавать нормально заголовки и реально сталкивался не раз с проблемой при наложении водяных знаков на изображения "на лету". В общем проще уж вообще отрубить Apache и поставить связку nginx+php-cgi но тут начнётся новые слёзы, когда вы начнёте переписывать правила перенаправлений под "понятный" nginx. В общем, начинаем читать дальше...

 

lighttpd

Этот маленький сервер точно также как nginx (а точнее nginx использует такую же как у lighttpd)  технологию обработки запросов и появился гораздо раньше. Причём если вы нацелены на огромное количество пользователей, то lighttpd свободно сможет обслужить такое количество, от которого и nginx загнётся. Переписывание перенаправлений дикий шок и ужас не вызовет, очень простая и понятная система конфигурации. Кто-то, правда, писал, что ему "что-то в конфиге не хватило", ну жираф большой... точно так же можно легко поставить связку с php-cgi чтобы получить полноценный веб-сервер.

 

На последок маленький тест производительности lighttp против nginx (ApacheBench 2.3, html - файл размером 3700 байт, миллион запросов):

Server Software: lighttpd/1.4.22
Finished 1000000 requests
Time taken for tests: 187.617 seconds
Total transferred: 3935633535 bytes
HTML transferred: 3700595700 bytes
Requests per second: 5330.02 [#/sec] (mean)
Time per request: 187.617 [ms] (mean)
Time per request: 0.188 [ms] (mean, across all concurrent requests)
Transfer rate: 20485.34 [Kbytes/sec] received

Server Software: nginx/0.7.62
Finished 1000000 requests
Time taken for tests: 216.531 seconds
Total transferred: 3912535944 bytes
HTML transferred: 3700506900 bytes
Requests per second: 4618.27 [#/sec] (mean)
Time per request: 216.531 [ms] (mean)
Time per request: 0.217 [ms] (mean, across all concurrent requests)
Transfer rate: 17645.66 [Kbytes/sec] received

В этом тесте lighttpd просто как тузик грелку разрывает хвалёный nginx:
1. Время выполнения:
nginx – 216.531 seconds
lighttpd – 187.617 seconds
lighttpd на 28,914 секунд выполнил тест быстрее

2. Пропускная способность
nginx – 17645.66 [Kbytes/sec]
lighttpd – 20485.34 [Kbytes/sec]
lighttpd на 2839,68 КБ (2,8 МБ) в секунду быстрее

Вы ещё сомневаетесь что лучше поставить?

3 Comments on “Apache + nginx? Спасибо, есть lighttpd”

1
Anonymous

Очень полезный пост, спасибо автору!

06.03.2015 в 20:50
2
Сергей

Обзор актуальный.
На сколько я понял, тестировали на статическом файле. А что если сделать миллион запросов к какому-то РНР скрипту с функционалом, например phpinfo(); ?
И какие результаты будут у Апача.
Если не сложно. Ждем результатов.
Удачи!

10.04.2015 в 09:35
3
ptipti

Дмитрий, вы ничего не поняли. У Апача проблема с буфером вывода, именно поэтому его и мурыжили со статичным файлом, через прокси nginx. Выполнение запросов к php-файлу ничем отличатся не будет, кроме того, что ещё какое-то время уйдёт на работу php. В nginx технология буферизации схожа с той, которая используется и в lighttp, именно поэтому все эти танцы с бубном, чтобы тяжкую статику для Апача переключить на что-то другое. А Апач остаётся только для работы .htaccess, ну очень грубо говоря. Причём nginx последней версии очень сильно огорчил, если через его прокси отдавать статические файлы функциями типа readfile, fpassthru или иными методами типа echo, то содержимое такое не отдаётся. Ну а самый главный момент — это количество пожираемых ресурсов. маленький lighttp просто проверяет их наличие 🙂 Кстати, с последними правилами перезаписи типа if_no_file, можно полноценно заменить все .htaccess файлы. Единственное неудобство — это всё равно необходимость прописывать настройки в файл кофигурации. Такой прелести, как просто кидать файл .htaccess куда угодно, кроме Апача никто не умеет.

10.04.2015 в 16:50

Leave a comment

*