Измерение производительности – скользкое дело, поскольку измерить именно то, что надо, удается весьма редко. Обычно требуется узнать, как система будет вести себя в реальной ситуации. Большая часть измерительных инструментов пытается имитировать (в определенной степени) именно такой сценарий, но это всегда получается в определенном приближении, и полученные данные никогда полностью не совпадают с реальностью. Как только вы поймете, что результаты измерений и проза жизни – вещи разные, эти инструменты станут полезными в ходе работы над ускорением вашего сервера.
Предложенные 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 дополнительными вопросами.