В настоящее время безусловным лидером среди Web-серверов на просторах Internet является Apache. Это самый функциональный Web-сервер, и, к тому же, большинство системных администраторов свободный UNIX-like систем в той или иной степени с ним сталкивались и умеют его конфигурировать. Также неоспоримым преимуществом является его портабельность (он есть практически подо все UNIX-like ОС, а также под Windows, MAC OS и OS/2).
Кроме того у каждого хостера, предоставляющего Linux или Free BSD хостинг установлен обычно именно он — родной и любимый Apache.
Однако у меня есть основания считать его в настоящее время не лучшим выбором для построения своего сайта. И я хочу описать здесь эти основания.
Первая является реально стабильной и чаще всего применяемой. Новых усовершенствований в неё давно не вносится, но и имеющегося набора функциональности хватает большинство пользователей за глаза.
Вторая имеет сильно переработаную архитектуру, кое-где позволяющую в теории добиться и большей производительности, и большей безопасности, и при этом большей портируемости (имеется в виду в первую очередь в не-UNIX системы). Но, увы, серьёзные проблемы безопасности в ней находят хорошо хоть не каждый день. И, несмотря на то что официально она именуется стабильной, реально это хорошее средство системному администратору сделать свою жизнь менее скучной.
В общем-то сейчас опытных администраторов эта мышиная возня слабо интересует, потому как 1.3.* работал, работает, и ещё ой как долго проработает.
Архитектура Apache
В 1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это отдельная нить, что несколько экономнее). Каждая копия Apache в среднем требует приблизительно 2Mb памяти (по моей статистике). 100 одновременных соединений — 200Mb памяти. 1000 одновременных соединений — 2G памяти. Для сайта крупной компании или для хостинга это очень большая проблема. А также это может стать крупной проблемой для любого сайта после лёгенькой Do S-атаки.
Вся удивительная функциональность Apache достигается за счёт модульной архитектуры. Все модули бинарные, поэтому ошибка в любом из модулей приводит... Да, к чему угодно в рамках конкретной дочки Apache. Опять же, слава богу, ввиду отлаженности большинства модулей это обычно не слишком важно. Но всё-таки существенно, ибо ошибка, например, в mod_ssl (что уже бывало) предоставляет доступ ко всем обслуживаемым ресурсам. С учётом роста возможностей, а также массы внешних расширений, написаных сторонними разработчиками (например самое распространённое такое расширение — mod_php) удерживать в полной безопаности такую систему становится сложно. Полноценного механизма разделения привелегий пока так и нет.
Ну и самое неприятное, портабельность вынуждает реализовывать не самую эффективную архитектуру, а самую универсальную. А разница между оптимальными подходами в Windows и UNIX-like ОС огромна.
Множество пользователей
Основной режим работе серверов (особенно в России, где больше всего подключений низкоскоростные) выглядит следующим образом:
подключается клиент, делает запрос;
так как чаще всего запрос обрабатыватся perl или php-скриптом, вызывается
этот скрипт (что происходит достаточно быстро);
результат отсылается пользователю (и этот период занимает больше
времени чем предыдущий);
Результат — дочка Apache, размером в 20Mb висит в памяти большую часть времени лишь для того, чтобы отдать пользователю запрос размером в 5–20Kb. До очарования идиотичная трата такого дорогостоящего ресурса, как память (которая чаще всего становится в серверах «бутылочным горлышком»).
squid / oops
Ясен пень, что администраторы (как и их руководство) не шибко любят тратить ресурсы сервера впустую. Поэтому (ну не только поэтому, конечно) было изоберетно такое гениальное средство как “reverse proxy”. Идея проста — пусть средство, предназначеное для быстрой передачи данных клиенту этим и занимается, а Apache просто подготавливает данные для отправки пользователю. Результат — экономия памяти и увеличение производительности. А если ещё авторы скриптов озаботились столь корректным их написанием, что прокси могут по возможности кэшировать их вывод, то экономия становится ещё более ощутимой.
Кроме того этот подход ещё и снижает нагрузку на базы данных, уменьшая количество одновременных запросов. Ещё один плюс такой технологии ускорения.
nginx, mathopd и другие
Ещё одна неприятность Apache — большие накладные расходы при передаче чисто статических данных. Обычно на одну генерируемую страницу приходится огромное количество изображений, которые в основном являются статическими данными, а не генерируются при каждом обращении (за исключением, разве что, счётчиков). Тут функциональность Apache играет против него.
Есть и ещё один важный момент. В Linux, особенно начиная с ядра 2.6, имеется масса усовершенствований для быстрой передачи по сети большим количеством одновременных потоков из однопоточного приложения. Apache не может воспользоваться большей частью этих усовершенствований.
Результат: nginx выдерживает на раздаче статического контента нагрузку по одновременному количеству соединений более чем в 100 раз большую.
А наличие в nginx, например, функций reverse proxy заставляет задуматься...
Fast CGI
Многие помнят почему всеми так любим 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.
Идеальная архитектура современного корпоративного Web-сервера
1-я линия это nginx, он и обрабатывает все входящие соединения.
обеспечивает https, если это надо
раздаёт чисто статический контент
формирует очередь из небольшого количества параллельных запросов, которые будут отданы серверу приложений
преобразование путей (nginx может заменить функциональность mod_rewrite).
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 г.
Любое распространение этой статьи без согласия автора запрещено