Вход:  Пароль:  
FreeSource: AntiApache ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

В этом мире есть не только Apache

Вступление

В настоящее время безусловным лидером среди Web-серверов на просторах Internet является Apache. Это самый функциональный Web-сервер, и, к тому же, большинство системных администраторов свободный UNIX-like систем в той или иной степени с ним сталкивались и умеют его конфигурировать. Также неоспоримым преимуществом является его портабельность (он есть практически подо все UNIX-like ОС, а также под Windows, MAC OS и OS/2).


Кроме того у каждого хостера, предоставляющего Linux или Free BSD хостинг установлен обычно именно он — родной и любимый Apache.


Однако у меня есть основания считать его в настоящее время не лучшим выбором для построения своего сайта. И я хочу описать здесь эти основания.

Устаревшее VS Ненадёжное

Сейчас есть две ветки Apache — 1.3.* и 2.*.


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


Вторая имеет сильно переработаную архитектуру, кое-где позволяющую в теории добиться и большей производительности, и большей безопасности, и при этом большей портируемости (имеется в виду в первую очередь в не-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 ОС огромна.

Множество пользователей

Основной режим работе серверов (особенно в России, где больше всего подключений низкоскоростные) выглядит следующим образом:





Результат — дочка 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, он и обрабатывает все входящие соединения.






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 г.
Любое распространение этой статьи без согласия автора запрещено

Страницы, ссылающиеся на данную: AltLinux/Dokumentacija/OpenVZ/Sharedhosting
Статьи



 
Файлов нет. [Показать файлы/форму]
Много комментариев (22). [Показать комментарии/форму]