В настоящее время безусловным лидером среди Web-серверов на просторах Internet является Apache. Это самый функциональный Web-сервер, и, к тому же, большинство системных администраторов свободный UNIX-like систем в той или иной степени с ним сталкивались и умеют его конфигурировать. Также неоспоримым преимуществом является его портабельность (он есть практически подо все UNIX-like ОС, а также под Windows, MAC OS и OS/2).
Кроме того у каждого хостера, предоставляющего Linux или Free BSD хостинг установлен обычно именно он — родной и любимый Apache.
Однако у меня есть основания считать его в настоящее время не лучшим выбором для построения своего сайта. И я хочу описать здесь эти основания.
Сейчас есть две ветки Apache — 1.3.* и 2.*.
Первая является реально стабильной и чаще всего применяемой. Новых усовершенствований в неё давно не вносится, но и имеющегося набора функциональности хватает большинство пользователей за глаза.
Вторая имеет сильно переработаную архитектуру, кое-где позволяющую в теории добиться и большей производительности, и большей безопасности, и при этом большей портируемости (имеется в виду в первую очередь в не-UNIX системы). Но, увы, серьёзные проблемы безопасности в ней находят хорошо хоть не каждый день. И, несмотря на то что официально она именуется стабильной, реально это хорошее средство системному администратору сделать свою жизнь менее скучной.
В общем-то сейчас опытных администраторов эта мышиная возня слабо интересует, потому как 1.3.* работал, работает, и ещё ой как долго проработает.
В 1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это отдельная нить, что несколько экономнее). Каждая копия Apache в среднем требует приблизительно 2Mb памяти (по моей статистике). 100 одновременных соединений — 200Mb памяти. 1000 одновременных соединений — 2G памяти. Для сайта крупной компании или для хостинга это очень большая проблема. А также это может стать крупной проблемой для любого сайта после лёгенькой Do S?-атаки.
Вся удивительная функциональность Apache достигается за счёт модульной архитектуры. Все модули бинарные, поэтому ошибка в любом из модулей приводит... Да, к чему угодно в рамках конкретной дочки Apache. Опять же, слава богу, ввиду отлаженности большинства модулей это обычно не слишком важно. Но всё-таки существенно, ибо ошибка, например, в mod_ssl (что уже бывало) предоставляет доступ ко всем обслуживаемым ресурсам. С учётом роста возможностей, а также массы внешних расширений, написаных сторонними разработчиками (например самое распространённое такое расширение — mod_php) удерживать в полной безопаности такую систему становится сложно. Полноценного механизма разделения привелегий пока так и нет.
Ну и самое неприятное, портабельность вынуждает реализовывать не самую эффективную архитектуру, а самую универсальную. А разница между оптимальными подходами в Windows и UNIX-like ОС огромна.
Основной режим работе серверов (особенно в России, где больше всего подключений низкоскоростные) выглядит следующим образом:
Результат — дочка Apache, размером в 20Mb висит в памяти большую часть времени лишь для того, чтобы отдать пользователю запрос размером в 5–20Kb. До очарования идиотичная трата такого дорогостоящего ресурса, как память (которая чаще всего становится в серверах «бутылочным горлышком»).
Ясен пень, что администраторы (как и их руководство) не шибко любят тратить ресурсы сервера впустую. Поэтому (ну не только поэтому, конечно) было изоберетно такое гениальное средство как “reverse proxy”. Идея проста — пусть средство, предназначеное для быстрой передачи данных клиенту этим и занимается, а Apache просто подготавливает данные для отправки пользователю. Результат — экономия памяти и увеличение производительности. А если ещё авторы скриптов озаботились столь корректным их написанием, что прокси могут по возможности кэшировать их вывод, то экономия становится ещё более ощутимой.
Кроме того этот подход ещё и снижает нагрузку на базы данных, уменьшая количество одновременных запросов. Ещё один плюс такой технологии ускорения.
Ещё одна неприятность Apache — большие накладные расходы при передаче чисто статических данных. Обычно на одну генерируемую страницу приходится огромное количество изображений, которые в основном являются статическими данными, а не генерируются при каждом обращении (за исключением, разве что, счётчиков). Тут функциональность Apache играет против него.
Есть и ещё один важный момент. В Linux, особенно начиная с ядра 2.6, имеется масса усовершенствований для быстрой передачи по сети большим количеством одновременных потоков из однопоточного приложения. Apache не может воспользоваться большей частью этих усовершенствований.
Результат: nginx выдерживает на раздаче статического контента нагрузку по одновременному количеству соединений более чем в 100 раз большую.
А наличие в nginx, например, функций reverse proxy заставляет задуматься...
Многие помнят почему всеми так любим mod_php. Любими он просто потому, что модуль, естественно быстрее чем вызывать интерпретатор каждый раз при обращении к скрипту (как это происходит в случае с CGI). В результате mod_php многократно выигрывает по скорости как у CLI php, так и у perl (не считая mod_perl, разумеется, но это отдельная долгая печальная история, почему большинство хостеров эту чудесную для программиста возможность предоставляют крайне редко). Так вот, Fast CGI даёт те же самые возможности и даже больше. В этом он ближе к mod_perl. Суть Fast CGI — скрипт вызывается один раз, а потом ему передаются запросы и забираются ответы. Это требует более внимательного программирования, однако даёт потрясающие возможности, такие как кэширование некоторых данных между сессиями, чего нет у mod_php (и что и даёт такое потрясающее преимущество по производительности хорошо написаным mod_perl скриптам).
Резюме: существование Fast CGI и поддержка его многими специализироваными «быстрыми» браузерами делает несущественным наличие mod_php. А тот факт, что php можно собрать и в виде fastcgi версии убивает одно из самых главных мнимых преимуществ Apache — то, что под него, якобы, заточен PHP.
Хорошим бысрым http-сервером, поддерживающим Fast CGI? является lighttpd.
1-я линия это nginx, он и обрабатывает все входящие соединения.
2-я линия это сервер приложений, любой http-сервер поддерживающий fastcgi. В случае наличия нескольких разных сервисов даже на одном сайте разумно запустить их под разными серверами — паранойя лучший друг системного администратора. Этим сервером, кстати, вполне может быть и старый добрый Apache, если вы к нему привыкли, или если есть какие-то специфические приложения. Но лучше заменить его чем-нибудь гораздо более лёгким.
3-я линия это, как обычно, My SQL? или Postgre SQL?, в зависимости от особенностей данного проекта и его моделей данных. Во многих случаях также может отсутствовать, будучи заменённым на встраиваемый движок баз данных sqlite (
http://www.sqlite.ru).
На крупном портале, или хостинг-сервисе имеет смысл первую линию разбить на несколько этпаов, выполняющихся на разных серверах, а также добавить кэширующий прокси-сервер, который бы держал все данные в памяти.
Описаные выше идеи далеко не новы, и известны многим специалистам. Увы, подход LAMP (Linux Apache My SQL? PHP) настолько вселился в души современных web-разработчиков, что они часто даже не задумываются о наличии альтернативных решений, более эффективных чем известные им сейчас.
Эта статья будет постоянно дорабатываться и корректироваться у меня на сайте, ибо тема эта неисчерпаема, и подлежит ещё долгому и ценному (я надеюсь) обсуждению.
Главное что я хотел показать этой статьей, это:
1. ни одним Apache единым жив сисадмин;
2. поставив и настроив пару лишних демонов можно сэкономить на апгрейде одного сервера столько, что не только на пиво, но и на пару походов с девушкой в ресторанчик хватит;
3. или, то же самое другими словами — правильная настройка системы гораздо важнее крутизны вашего сервера :)
подписка на новости сайта и полные тексты статей
(C) Денис Смирнов <mithraen@freesource.info>, 15 Dec 2004 г.
Любое распространение этой статьи без согласия автора запрещено
Если надо раздавать много статики – стоит завести отдельный хост вида images.our-site.com, downloads.our-site.com итд., и туда ставить ngix. Это я обеими руками поддерживаю.
А вот за PHP, который стоит за reverse proxy и у которого в $_SERVER["REMOTE_ADDR"] всегда торчит 127.0.0.1, я бы кое-что пообрывал сисадмину. Это я как разработчик говорю.
Граждане, избегайте reverse proxy! Если нагрузка большая – ставьте вторую машину (или берите другую ip-шку), выносите статику (по крайней мере, самую «тяжелую» по нагрузке) в отдельный хост и не морочьте разработчикам голову. Да и себе заодно.
Последнему анониму — и Вам спасибо :) Есть mod_realip для Apache, который в переменную REMOTE_ADDR подставляет взятые из Via данные, так что разработчики ничего не замечают. Для других серверов, насколько мне известно, ПОКА такой возможности нет. Я подумываю реализовать на эту тему патчик к lighttpd.
Дорогой Денис Смирнов!
Почему вы не хотите писать заметки с молотком в руке? Прикурутил – описал.
А хотите писать заметки на основе слухов?
Как вы хотите разгрузить сервер приложений на Apache при помощи nginx?
Почему вы не хотите понять сути «проксирования» и ее отличия от «кеширования»?
Apache 2? сильно быстрее на тяжелом бекенде. Ну сильно. В общем, я сержусь на жизнь.
За то, что приходится такое читать.
Стоит отметить, что существует весьма мощный web сервер AOLServer, позиционируемый для больших нагруженных сайтов. Распространяется он под свободной лицензией, внутрь встроен Tcl интерпретатор(есть и другие подключаемые языки), есть хороший продуманный API, в том числе и для БД. Смотреть на http://aolserver.com/, там же и модули для него.
Alexander Danilov <alex at fssg dot st-oskol dot ru>
Для анонима — повторяю медленно. По слогам. То, что уже описано выше.
Процесс передачи контента пользователю далеко не мгновенный. Если это диалапщик, то он может занимать секунды, при том, что генерируется этот контент доли секунды. Всё это время эта конкретная дочка апача жрёт впустую память (единицы мегабайт) и ничего не делает.
nginx забирает данные с backend'а с той скоростью, с которой тот его выдаёт. После чего медленно и печально отдаёт данные пользователю.
Теперь ясно?
Да, для тех кто не понял — мои заметки пишутся как раз на базе моего _опыта_. Nginx (как легко можно заметить) используется на сервере, на котором расположен этот сайт.
Дорогой Денис! Разгрузка бекенда это – разгрузка бекенда. Если нынче поутру кто-то запросил у тяжелого бекенда
(а «тяжелый» – это не «нагруженный», тяжелый – это ресурсоемкий) некий УРЛ, то все остальные 10000 юзеров запросивших
тот же УРЛ должны получить статику, снятую и сохраненную для них акселератором.
Похоже на то, как если бы вы сохранили себе на диск результат поиска слова «Мудак» в Яндексе и выдавали бы эту
статику своей маме каждый раз, когда она по вам заскучает. Мама ваша и баба ваша и деда ваша 100 000 раз в сутки
любуются на то, что вы известны всему свету, а Яндекс – отдыхвает. Это называется разгрузка бекенда.
Я думаю, что вы – идиот.
Для особо умных и выпендрёжных анонимов:
1. я прекрасно знаю зачем нужно _кэширование_
2. некоторые особо умные личности почему-то так и не поняли, что существует масса ресурсов где _каждому_ пользователю предоставляется _разный_ контент по одному и тому же адресу. И кеширование тут не поможет. А вот быстрая раздача статики и разделение сервисов генерирующих контент и раздающих его может экономить ресурсы в разы.
3. прежде чем выпендриваться, очень прошу, сначала взять и протестировать, если думать не получается
Это конечно очень красивая архитектура, но, увы, будет полезна когда на корпоративные сайты будут ставить машинки с производительностью не в тысячи, а в сотни тысяч MIPS :)
Денис, большое спасибо! Доходчивая и полезная статья, но уж слишком короткая. Имеет смысл написать подробнее, с детализацией и примерами конфигурации всех перечисленных способов.
Что именно вам хотелось бы увидеть уточнённым? Примеры конфигурации всех способов, это уже слишком :)
меня интересует возможность полной замены связки Apache+PHP на сервер nginx. можно узнать попобробнее как обрабатывать PHP-скрипты этим сервером?
Нет, увы. Нужен какой-то сервер, поддержквающий CGI. lighttpd, например.
Добавлю пару слов насчет lighttpd.
Про поддержку Fast CGI? в lighttpd лучше не вспоминать. Она там разве что формально есть, но после хорошей возни с этим чудом на пару с Витей Форсюком могу только сказать, что «фтопку его». Он там на уровне очень ранней альфы.
Еще один глюк lighttpd описывали – при возрастании нагрузки начинал отдавать исходники перлового скрипта вместо результатов его работы. Тоже забавно весьма ;)
А вот связка «apache + mod_fastcgi + squid» мне даже очень понравилась. Особенно, когда пришлось NTLM привязывать, который в squid работает, в отличие от mod_ntlm. :)
php собранный с --enable-fastcgi и размноженный lighttpd'овским spawn-fcgi – очень даже неплохо работает
Добавлю пару слов насчет lighttpd.
Товарищи не правы. Стоит на продакшн и пашет как зверь. УРЛ не скажу – уроните. Но lighttpd не виноват что ПЫХПЫХ по СЕКУНДЕ на запрос тратит (руки б оторвал вэб-программерам, но не могу).
Fast CGI? в PHP – фикция. На деле там эмуляция FCGI – в памяти висит процесс, который по требованию запускает копию PHP
php-mmcache.http://eaccelerator.net/(из переписки с Andrei Bulava)
хех ;-) http://mod-rewrite-wizard.com/
Powered by WackoWiki R4.2