один день из жизни IRC-канала #apache или как заставить сервер работать быстрее

Эта статья – часть цикла публикаций, основанных на обсуждениях, ведущихся на IRC-канале #apache.
Для справки: #apache – это IRC-канал, действующий в сети irc.freenode.net. Если вы желаете подключиться к нему, вам потребуется установить IRC-клиент (например, XChat, MIRC или bitchx).
Желаете узнать, как ускорить работу вашего web-сайта? Советы Рича помогут вам повысить производительность своего сервера.


для затравки

Я написал этот материал во время OSCON. Сейчас утро, пятница. Я должен был сдать статью в четверг вечером. Поэтому благодарю редактора /* впервые текст был опубликован на ONLamp.com – прим. ред. СР */ за понимание и, перефразируя Дугласа Адамса, приведу парочку мудрых слов от fajita:
<DrBacchus>fajita: сроки
<fajita>Самое замечательное качество всех сроков – это тот свист, с которым они пролетают мимо нас.
Итак, сегодня мы обсуждаем довольно типичный вопрос, который возникает по несколько раз на неделе:

<Quixote>Как заставить мой сервер работать быстрее?

Как вы догадываетесь, ответы могут быть самыми разными. Они зависят в первую очередь от контента, который вы держите на своем веб-сервере и тех настроек сервера, которые вы уже делали самостоятельно. Таким образом, подойти к решению данного вопроса можно с разных сторон. В связи с этим, вначале озвучу факт, который может вас определенным образом заинтересовать: на сайте Apache есть документ, некоторым образом связанный с освещением данной проблемы. Его можно найти по адресуhttp://httpd.apache.org/docs-2.0/misc/perf-tuning.html.Поэтому мы начнем с другого вопроса:

<Quixote>Как мне измерить производительность сервера?
<DrBacchus>fajita: Бенчмарками
<fajita>Некоторые доступные варианты – ab, flood, jmeter, daiquiri, siege

Измерение производительности – скользкое дело, поскольку измерить именно то, что надо, удается весьма редко. Обычно требуется узнать, как система будет вести себя в реальной ситуации. Большая часть измерительных инструментов пытается имитировать (в определенной степени) именно такой сценарий, но это всегда получается в определенном приближении, и полученные данные никогда полностью не совпадают с реальностью. Как только вы поймете, что результаты измерений и проза жизни – вещи разные, эти инструменты станут полезными в ходе работы над ускорением вашего сервера.
Предложенные fajita программы распространяются свободно и обладают различным уровнем функциональности. Я не собираюсь посвящать данную статью рассказу о них, мы будем рассматривать только ab, поскольку он поставляется вместе с Apache и представляет собой удобную стартовую позицию для измерений производительности.
Познакомиться с другими пакетами вы можете, обратившись к следующим ресурсам:
- Flood -http://httpd.apache.org/test/flood/.
- JMeter -http://jakarta.apache.org/jmeter/index.html.
- Daiquiri -http://www.omniti.com/~jesus/projects/daiquiri.README.
- Siege -http://joedog.org/siege/.
Итак, давайте немного поговорим об использовании ab.
Ab – это простой инструмент измерения производительности. Не впадайте в заблуждение насчет того, что он пытается каким-либо образом симулировать реальную ситуацию. Тем не менее, он полезен для экспериментального фиксирования разницы в производительности при изменении настроек сервера. Ab многократно запрашивает URL, а затем сообщает некоторую статистику о транзакции.

ab -n 1000 -c 10 >http://localhost/index.html

А вот часть результата выполнения этой команды:

Concurrency Level: 10
Time taken for tests: 2.303 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 253260 bytes
HTML transferred: 12060 bytes
Requests per second: 434.22 [#/sec] (mean)
Time per request: 23.03 [ms] (mean)
Time per request: 2.30 [ms] (mean, across all concurrent requests)
Transfer rate: 109.97 [Kbytes/sec] received

Данный отчет дает сведения о некоторых базовых значениях скорости работы определенного ресурса, благодаря чему мы можем наблюдать изменения, которые происходят при изменении конфигурации сервера. Теперь, когда у вас есть способ проверить работоспособность моих рекомендаций, перейдем к делу.

DNS

Избегайте обращений к DNS когда это только возможно. Это тормоз, который вам не подвластен. DNS-преобразования требуют ровно столько времени, сколько они требуют. Следовательно, вам необходимо запретить Apache их использование.
Мы можем повлиять на данную ситуацию в двух точках: при контроле доступа и при записи логов.
Если для контроля доступа, основанном на адресе клиента, вы используете в своем конфигурационном файле директивы allow from или deny from, старайтесь использовать не имя хоста, а IP-адрес клиента, которого вы желаете пропустить (или отвадить). Когда вы используете имя хоста, Apache приходится запрашивать DNS для того, чтобы выяснить, пришел ли запрос от обозначенного хоста.
В конфигурационном файле присутствует директива HostNameLookups. Если она установлена в Off (по умолчанию), Apache будет помещать IP-адрес клиента в лог. Если она установлена в On, то в лог пойдет имя хоста.
Не делайте этого.
Если вы заставите Apache обращаться к DNS при каждом запросе клиента, производительность сервера неизбежно упадет. Кроме того, Apache будет запускать большее количество дочерних процессов, поскольку его процессы будут тратить время на обращение к DNS.

файлы .htaccess

Если говорить кратко - вы должны избегать использования файлов .htaccess насколько это только возможно. Их применение ведет к очень большим потерям в производительности. Для этого есть несколько причин.
Во-первых, Apache вынужден обращаться к файлам .htaccess каждый раз, когда поступает запрос к каталогу ресурса. Файлы .htaccess не кэшируются и вносимые в них изменения вступают в силу немедленно. Следовательно, Apache необходимо каждый раз проверять этот файл, что означает его открытие, чтение и парсинг при каждом запросе.
И это еще не все! Поскольку файлы .htaccess применяются и к подкаталогам, Apache придется тоже их проверить. Если есть еще один уровень вложения – то проверить и его, и так далее, до тех пор, пока не будет достигнут тот уровень, где заканчиваются полномочия .htaccess.
Что это означает? А то, что каждый запрос к определенному каталогу генерирует 2, 3, 4 и т.д. запроса на доступ к файловой системе. Даже если в этих каталогах нет файлов .htaccess, Apache все равно будет их там искать.
Мораль проста: установка AllowOverride None везде, где только можно. Если использование .htaccess все-таки необходимо, активируйте эту функцию только для конкретных каталогов. Еще лучше будет поместить соответствующие директивы в httpd.conf.
Да, есть случаи, когда файлы .htaccess полезны. Я только полагаю, что они встречаются не так часто, как считают некоторые товарищи.

Content Negotiation

Content Negotiation – это возможность использования настроек браузера клиента для предоставления ему определенной языковой версии ресурса (если есть несколько таких вариантов). Это прекрасная возможность, однако, в плане требуемых ресурсов производительности она обходится довольно дорого. Не включайте ее, если она вам не нужна. На практике это означает удаление директивы MultiViews из раздела Options вашего конфигурационного файла.

другие ресурсы

Приведенный список мер, само собой, не является абсолютно полным. Много интересных сведений можно почерпнуть в ходе изучения документации на веб-сайте Apache. Смотритеhttp://httpd.apache.org/docs/misc/perf-tuning.htmlдля Apache 1.3 иhttp://httpd.apache.org/docs-2.0/misc/perf-tuning.htmlв случае Apache 2.0.
Однако наибольшее количество ошибок совершается в рассмотренных нами ситуациях, поэтому данная статья – хороший начальный пункт для начала дальнейшего поиска.
Другие вещи, требующие вашего внимания – это mod_deflate и mod_file_cache.
Если вы пользуетесь Apache 1.3, то вам потребуются соответствующие аналоги: mod_gzip и mod_mmap_static.
Если вы применяете CGI-программы, написанные на Perl, то вам следует уделить внимание mod_perl (perl.apache.org).
Ну и, конечно, обращайтесь на #apache c дополнительными вопросами.


Rich Bowen, перевод Алексея Кутовенко.