Отправляет email-рассылки с помощью сервиса Sendsay

freesource.info: новости проекта и статьи

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "[Linux и BSD]: новости, статьи, свежий софт от LinuxRSP.RU" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Декабрь 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Фёдор Сорекс

Статистика

1.116 подписчиков
-1 за неделю
←   Все выпуски   →

freesource.info: новости проекта и статьи Оптимизация Web-проектов


Информационный Канал Subscribe.Ru

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

Вступление

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

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

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

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

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

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

Вторая имеет сильно переработаную архитектуру, кое-где позволяющую в теории добиться и большей производительности, и большей безопасности, и при этом большей портируемости (имеется в виду в первую очередь в не-UNIX системы). Но, увы, серьёзные проблемы безопасности в ней находят хорошо хоть не каждый день. И, несмотря на то что официально она именуется стабильной, реально это хорошее средство системному администратору сделать свою жизнь менее скучной.

В общем-то сейчас опытных администраторов эта мышиная возня слабо интересует, потому как 1.3.* работал, работает, и ещё ой как долго проработает.

Архитектура Apache

В 1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это отдельная нить, что несколько экономнее). Каждая копия Apache требует приблизительно 20Mb памяти. 100 одновременных соединений -- 200Mb памяти. 1000 одновременных соединений -- 2G памяти. Для сайта крупной компании или для хостинга это очень большая проблема. А также это может стать крупной проблемой для любого сайта после лёгенькой DoS-атаки.

Вся удивительная функциональность 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-сервером, поддерживающим FastCGI является lighttpd.

Идеальная архитектура современного корпоративного Web-сервера

1-я линия это nginx, он и обрабатывает все входящие соединения.

- обеспечивает https, если это надо

- раздаёт чисто статический контент

- формирует очередь из небольшого количества параллельных запросов, которые будут отданы серверу приложений

- преобразование путей (nginx может заменить функциональность mod_rewrite).

2-я линия это сервер приложений, любой http-сервер поддерживающий fastcgi. В случае наличия нескольких разных сервисов даже на одном сайте разумно запустить их под разными серверами -- паранойя лучший друг системного администратора. Этим сервером, кстати, вполне может быть и старый добрый Apache, если вы к нему привыкли, или если есть какие-то специфические приложения. Но лучше заменить его чем-нибудь гораздо более лёгким.

3-я линия это, как обычно, MySQL или PostgreSQL, в зависимости от особенностей данного проекта и его моделей данных. Во многих случаях также может отсутствовать, будучи заменённым на встраиваемый движок баз данных sqlite (http://www.sqlite.ru).

На крупном портале, или хостинг-сервисе имеет смысл первую линию разбить на несколько этпаов, выполняющихся на разных серверах, а также добавить кэширующий прокси-сервер, который бы держал все данные в памяти.

Резюме

Описаные выше идеи далеко не новы, и известны многим специалистам. Увы, подход LAMP (Linux Apache MySQL PHP) настолько вселился в души современных web-разработчиков, что они часто даже не задумываются о наличии альтернативных решений, более эффективных чем известные им сейчас.

Эта статья будет постоянно дорабатываться и корректироваться у меня на сайте, ибо тема эта неисчерпаема, и подлежит ещё долгому и ценному (я надеюсь) обсуждению.

Главное что я хотел показать этой статьей, это:

1. ни одним Apache единым жив сисадмин;

2. поставив и настроив пару лишних демонов можно сэкономить на апгрейде одного сервера столько, что не только на пиво, но и на пару походов с девушкой в ресторанчик хватит;

3. или, то же самое другими словами -- правильная настройка системы гораздо важнее крутизны вашего сервера :)

Обсудить статью можнно на http://freesource.info/forum/

(C) Денис Смирнов <mithraen@freesource.info>, 15 Dec 2004 г. Любое распространение этой статьи без согласия автора запрещено

http://subscribe.ru/
http://subscribe.ru/feedback/		 Подписан адрес:
Код этой рассылки: comp.soft.linux.freesource		 Отписаться
В избранное