Другой способ - просто увеличить производительность сервера - поставить более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.
Запускайте apache только с необходимыми модулями, чтобы уменьшить потребление памяти. Если вы решили скомпилировать apache самостоятельно, то либо тщательно подходите к выбору списка модулей, которые вы включите, либо компилируйте их как DSO используя apxs в apache1 и apxs2 в apache2. Для того чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Apache со статически скомпилированными модулями будет потреблять чуть меньше памяти, однако вам придется каждый раз его перекомпилировать для изменения списка модулей.
Выбор MPM зависит от нескольких факторов, таких как наличие поддержки потоков в ОС, количества свободной памяти, а также требований стабильности и безопасности.
Если безопасность очень важна, следует выбрать peruser MPM, пожертвовав производительностью.
Если важна именно производительность, то выбор ограничивается двумя mpm: prefork и worker.
Worker - поточный MPM, т.е. в нем каждый запрос обслуживается в отдельном потоке одного из дочерних процессов. Потоки - более легкие для ОС объекты, чем процессы, они более эффективно используют память и переключения контекста для них происходят быстрее. Однако, из-за того что каждый поток имеет доступ ко всей памяти процесса, worker mpm более подвержен сбоям: сбой одного потока может повлечь падение всего процесса, в котором находился этот поток (именно поэтому worker mpm запускает несколько дочерних процессов с несколькими потоками в каждом).
Perfork - mpm использует несколько дочерних процессов, каждый дочерний процесс обрабатывает одно подключение. Из-за того что процесс - более тяжелая структура, он использует немного больше ресурсов, зато он менее подвержен сбоям - обработка каждого отдельного запроса не зависит от других процессов.
К сожалению, для смены mpm требуется перекомпиляция apache. Тут проявляют свои достоинства source-based дистрибутивы: вы можете легко перекомпилировать apache и все зависимые от него пакеты, не превратив систему в свалку. Бинарные дистрибутивы выходят из этой ситуации по-разному. Например в RHEL в apache rpm находится сразу две версии apache - с worker и prefork mpm (prefork используется по умолчанию). Однако worker mpm не поддерживает php. Так что если вы хотите php и worker mpm вам придется компилировать его самостоятельно либо искать сторонние репозитории.
Кроме того, следите чтобы в директивах Allow from и Deny From использовались ip-адреса а не доменные имена. Иначе apache будет делать два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за кого себя выдает.
DocumentRoot /var/www/html
Если будет запрошен /index.html, apache попытается открыть (и интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так что, если вам нужен.htaccess только для одной директории, разрешайте его только для нее:
DocumentRoot /var/www/html
Кроме того, дополнительные системные запросы требуются когда FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. наиболее оптимальная ситуация для производительности - когда опция FollowSymlinks включена.
Вы можете прикинуть примерный размер посмотрев на колонку rss в выводе `ps -ylC httpd --sort:rss`
Если сервер уже обслуживает MaxClients запросов, новые запросы попадут в очередь, размер которой устанавливается с помощью директивы ListenBacklog.
Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом. Это - сигнал того что MinSpareServers слишком мало.
Кеширование конфигурируется директивами модуля mod_deflate. Имейте в виду, что не следует устанавливать степень сжатия gzip более 4-5 - это потребует существенно большего времени CPU, а эффект будет достаточно невелик. Ну и разумеется не нужно пытаться сжать изображения в jpg, gif и png, музыку, видео файлы и все другие бинарные файлы, которые уже и так хорошо сжаты.
Оригинал: "Configuring Apache for Maximum Performance". Vishnu Ram V: http://linuxgazette.net/123/vishnu.html
Популярность веб-страницы – не только благо, но и дополнительная головная боль сисадмина. Возрастая, поток посетителей создает большую нагрузку на сервер, который со временем перестает справляться со своими обязанностями. В этот момент встает вопрос о покупке железа, который, тем не менее, можно отложить до лучших времен. Из этой статьи ты узнаешь, как заставить сервер выдерживать нагрузки даже тогда, когда он отказывается это делать.
Популярность веб-страницы - не только благо, но и дополнительная головная боль сисадмина. Возрастая, поток посетителей создает все большую нагрузку на сервер, который со временем просто перестает справляться со своими обязанностями. В этот момент встает вопрос о покупке железа, который, тем не менее, можно отложить до лучших времен. Из этой статьи ты узнаешь, как заставить сервер выдерживать нагрузки даже тогда, когда он отказывается это делать.
Допустим, ты имеешь в своем распоряжении веб-сервер, на котором крутится более-менее посещаемый динамический веб-сайт, созданный на базе одной из PHP’шных CMS. В общем, самая типичная для современного рунета ситуация. Сайт развивается, растет, посетителей становится все больше, и ты начинаешь замечать постепенно возрастающие задержки в скорости отдачи контента. Простейшие замеры показывают, что сервер уже не справляется с возложенными на него задачами, и в голову начинают закрадываться порочные мысли о покупке железа (аренде более мощного виртуального сервера). Но спешить не стоит, в большинстве случаев ситуацию легко обратить в свою пользу.
Эта статья расскажет тебе о том, как оптимизировать сервер и клиентскую часть веб-сайта под высокую нагрузку. В ходе обсуждения мы затронем следующие темы:
Корневой компонент большинства современных веб-сайтов - это, конечно же, Apache. Он зарекомендовал себя как наиболее функциональный, стабильный и удобный в использовании HTTP-сервер, который можно использовать как для обслуживания домашней веб-страницы, так и для высоконагруженных корпоративных интернет-проектов. Одна проблема: Apache - очень тяжелое приложение, жадное до ресурсов сервера.
И это должно быть учтено при его настройке. Вот список рекомендаций, которые лучше выполнять при подготовке HTTP-сервера к работе:
Всего их существует три:
Многие дистрибутивы позволяют устанавливать разные варианты Apache, различающиеся используемым MPM, их легко можно найти в репозитории по запросу «apache2-mpm».
Зачастую наибольшая нагрузка создается вовсе не HTTP-сервером, а интерпретатором языка программирования, используемого для создания динамического содержимого веб-сайта. Сегодня наиболее популярным языком для серверного веб-скриптинга является PHP, поэтому именно ему мы уделим внимание в нашей статье. Открываем файл /etc/php5/ apache2/php.ini (путь для Ubuntu, в других дистрибутивах может быть иным) и редактируем следующие строки:
Теперь можно закрыть файл и выполнить глубокую оптимизацию с помощью PHP-ускорителя.
PHP - язык интерпретируемый. Это значит, что каждый раз, когда происходит вызов скрипта на этом языке, запускается PHP-интерпретатор, который проводит полный анализ исходного кода. Причем, если спустя секунду произойдет второй запуск того же скрипта, вся процедура будет повторена заново. Это нерациональное использование ресурсов, поэтому мы применим инструмент под названием eAccelerator, который скомпилирует исходные тексты PHP в двоичное представление, оптимизирует их и будет бережно хранить в оперативной памяти для более быстрого доступа. Благодаря только этому скорость обработки PHP-скриптов вырастет в десятки раз (подтверждено тестами).
Пакета eAccelerator нет в репозиториях популярных дистрибутивов, поэтому его придется собрать самостоятельно. Сначала устанавливаем необходимые для сборки утилиты:
$ sudo apt-get install php5-dev build-essential
$ cd /tmp/
$ wget http://bart.eaccelerator.net/source/0.9.6.1/
eaccelerator-0.9.6.1.tar.bz2
$ tar xvjf eaccelerator-0.9.6.1.tar.bz2
$ cd eaccelerator-0.9.6.1
$ phpize
$ ./configure --enable-eaccelerator=shared
$ make
$ sudo make install
Создаем каталог для хранения кэша:
$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator
И, наконец, подключаем eAccelerator к PHP (добавить в начало файла):
# vi /etc/php5/apache2/php.ini
; Подключаем расширение
extension = "eaccelerator.so"
eaccelerator.enable = "1"
; Максимальный размер дискового кэша (Мб)
eaccelerator.shm_size = "64"
; Каталог для хранения кэша
eaccelerator.cache_dir = "/var/cache/eaccelerator"
; Включаем оптимизатор кода
eaccelerator.optimizer = "1"
; Перекомпилировать модифицированные скрипты
eaccelerator.check_mtime = "1"
; Отключаем режим отладки
eaccelerator.debug = "0"
; Кэшировать все файлы (пустой фильтр)
eaccelerator.filter = ""
; Неограниченный размер кэша в памяти
eaccelerator.shm_max = "0"
; В случае отсутствия места в кэше удалять объекты старше
1 часа (3600 секунд)
eaccelerator.shm_ttl = "3600"
eaccelerator.shm_prune_period = "0"
; Кэшировать данные и в памяти, и на диске
eaccelerator.shm_only = "0"
; Сжимать кэшированные данные с максимальным уровнем компрессии
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
Будучи популярным, большой динамический веб-сайт может создать такую нагрузку на сервер, что Apache начнет «захлебываться и плеваться».
И дело тут даже не в том, что железо не позволяет, а в тяжеловесности самого HTTP-сервера. Apache отлично подходит для отдачи динамического контента, однако большая часть современных веб-страниц так или иначе состоит из статики, и использовать для их отдачи мощный, сложный и очень тяжелый HTTP-сервер было бы так же глупо, как ездить на вездеходе по дорогам Швейцарии. Мы воспользуемся легковесным HTTP-сервером Nginx для разгрузки Apache и его освобождения от неблагодарного занятия отдачей статического контента. В отличие от Apache, Nginx использует событийную модель обработки запросов, благодаря чему на любое количество клиентов требуется всего один процесс HTTP-сервера.
Это существенно снижает нагрузку на железо, но создает определенные проблемы при обработке динамического контента (именно поэтому его не используют в качестве основного HTTP-сервера). Обычно Nginx устанавливают на выделенную машину, которая смотрит во внешнюю сеть и выступает в качестве первого чекпоинта на пути следования запросов, однако допустим и вариант с одним физическим сервером, когда Apache и Nginx крутятся на одной машине. Остановимся на нем. Открываем файл /etc/apache2/ports.conf и изменяем две опции:
NameVirtualHost *:81
Listen 81
Далее устанавливаем Nginx:
$ sudo apt-get install nginx
Открываем конфигурационный файл и пишем в него следующее:
# vi /etc/nginx/nginx.conf
# Nginx-пользователь
user www-data;
# Количество Nginx-процессов ставим равным количеству
процессорных ядер
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
# Стандартные настройки
include /etc/nginx/mime.types;
default_type application/octet-stream;
server_names_hash_bucket_size 64;
access_log /var/log/nginx/access.log;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
tcp_nodelay on;
# Включаем сжатие
gzip on;
gzip_proxied any;
gzip_min_length 1100;
gzip_http_version 1.0;
gzip_buffers 4 8k;
gzip_comp_level 9;
gzip_types text/plain text/css application/
x-javascript text/xml application/xml
application/xml+rss text/javascript;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Создаем конфиг нашего хоста:
# vi /etc/nginx/sites-enabled/host.com
server {
listen 80;
server_name host.com;
access_log /var/log/nginx.access_log;
# Всю статику Nginx отдает самостоятельно
location ~* \.(jpg|jpeg|gif|png|css|js|zip|
tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bm
p|rtf|swf|ico|flv|txt|xml|docx|xlsx)$ {
root /var/www/host.com/;
index index.html index.php;
access_log off;
expires 30d;
}
# Доступ к файлам типа.htaccess запрещен
location ~ /\.ht {
deny all;
}
# Все запросы ко всему остальному контенту передаем Apache
location / {
proxy_pass http://127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-for $remote_
addr;
proxy_set_header Host $host;
proxy_connect_timeout 60;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_redirect off;
proxy_set_header Connection close;
proxy_pass_header Content-Type;
proxy_pass_header Content-Disposition;
proxy_pass_header Content-Length;
}
}
Все, перезапускаем Apache и Nginx:
$ sudo service apache2 restart
$ sudo service nginx restart
Memcached - система кэширования данных в оперативной памяти, которая может быть использована для распределенного хранения и ускорения доступа к данным любого типа.
Это одно из самых популярных решений в области тотальной оптимизации веб-сайта для высоких нагрузок, не требующее настройки и долгого изучения API. Обычно memcached используется, так сказать, двумя сторонами, одна из которых помещает данные в кэш, а другая - извлекает. В веб-среде роль первой стороны обычно играет небольшой PHP-скрипт, который записывает важные (с точки зрения скорости отдачи) данные в memcached, в то время как вторая сторона - это обычно легковесный фронт-энд сервер (как правило, nginx), использующий специальный модуль для чтения и отдачи данных из memcached. Часто memcached используется для кэширования всех страниц веб-сайта целиком, благодаря чему скорость доступа к этим страницам возрастает на несколько порядков. В простейшем случае такая конфигурация выглядит следующим образом:
1. Устанавливается memcached:
$ sudo apt-get install memcached
2. В секцию server конфигурационного файла nginx добавляе тся примерно следующее:
# vi /etc/nginx/nginx.conf
location / {
# Устанавливаем ключ memcached, равный запрашиваемому
URI
set $memcached_key $uri;
# Адрес и порт демона memcached
memcached_pass 127.0.0.1:11211;
# Заголовок по умолчанию
default_type text/html;
# Если данные в кэше не найдены - запрашиваем их у бэкэнда
error_page 404 = /fallback;
}
location /fallback {
proxy_pass backend;
}
3. Для PHP устанавливается расширение memcache (клиент к memcached):
$ sudo pecl install memcache
4. В страницы встраивается примерно такой код:
$ vi smaple.php
# Инициализация memcached опущена
ob_start();
$html = ob_get_clean();
$memcache->set($_SERVER["REQUEST_URI"], $html);
echo $html;
Все это отлично работает, но только в отношении очень простых, почти статических веб-сайтов. Дело в том, что страница не всегда должна быть одинаковой для всех посетителей. Что если главная страница будет закэширована при входе на сайт гостя, а после него на сайт придет зарегистрированный участник, которому вновь предложат зарегистрироваться.
Непорядок. Однако есть достаточно простой выход из этой ситуации. Проблему может решить покрытая мхом и паутиной технология под названием SSI (Server Side Includes). SSI позволяет разбить веб-страницу на несколько блоков, которые будут собраны фронт-эндом воедино в момент обработки запроса клиента. Например, используя SSI, ты делишь главную страницу веб-сайта на две части:
# vi /var/www/index.php
Это ровно та же страница, код аутентификации которой вынесен в файл auth.php, а вся остальная часть - в body.php. Изюминка же заключается в том, что приведенный выше в четвертом шаге код кэширования ты помещаешь только во второй из этих файлов. Как результат вырисовывается следующая картина:
Само собой разумеется, SSI необходимо активировать в конфигурационном файле nginx с помощью опции «ssi on», помещенной в секцию «location /». Стоит отметить, что блок auth.php также поддается кэшированию, но для этого придется присваивать всем зарегистрированным пользователям идентификатор, сохранять его в кукисах и использовать для генерации уникального ключа memcached.
Эта статья посвящена серверной оптимизации веб-сайтов, однако было бы кощунством не рассказать и о клиентской части этого процесса. Поэтому мы кратко пробежимся по списку рекомендаций, направленных на минимизацию общего объема передаваемых данных:
Round robin DNS - один из самых простых видов балансировки нагрузки. Для ее реализации достаточно присвоить IP-адреса двух или более серверов одному доменному имени. Однако, есть и существенный минус: если один из серверов выйдет из строя, часть клиентов все равно будут отправлены к нему.
При наличии достаточно больших объемов памяти хорошей практикой будет запуск демона memcached с флагом ‘-L’. В результате демон заранее подготовит к использованию всю выделенную ему память. Это немного поднимет общую производительность работы memcached за счет исключения необходимости производить постоянные выделения памяти во время работы.
Сегодня я расскажу о том, как сделать Apache немного быстрее. Кто-то спросит — «зачем?.. есть же более быстрые решения!»….
Таким товарищам я отвечу что да, есть, что они быстрее, например на одной жестяной банке я использую связку Apache+Nginx (даже писал об этом), можно использовать Nginx с модулем FastCGI.. И об этом я напишу, не в этой статье, но напишу..
Но сейчас речь пойдет о том, как сделать Apache немного быстрее, адекватнее и безопаснее. Картинка, тег «more» и пошла статья…
Первое, самое основное, что-то типа «спасибо-кэп» — Apache нужно запускать с необходимыми модулями, чтобы уменьшить потребление памяти.
Для их отключения можно воспользоваться командами a2dismod <имя_модуля> а потом перезапустить конфигурацию сервера. Если вы отключите что-то не то, то включить модуль можно командой a2enmod <имя_модуля>. Опять же смотрите что отключайте, иначе какие-то функции ваших проектов могут перестать работать.
Кстати, как правило, кроме этих перечисленных модулей вам больше ничего не нужно:
Mod_alias mod_authz_host mod_deflate mod_dir mod_expires mod_headers mod_mime mod_rewrite mod_log_config mod_autoindex mod_negotiation mod_setenvif
В apache каждый запрос обрабатывается в своем процессе или потоке. При компиляции apache позволяет выбирать один из нескольким MPM (Multi-processing module), которые отвечают за прослушивание портов, прием запросов и раздачу этих запросов дочерним процессам или потокам, в которых эти запросы будут обработаны.
Если безопасность важна — выбирайте peruser MPM. Если важна производительность, то выбирайте prework или worker.
По мне так Worker — самый оптимальный вариант.
Чтобы узнать какой у вас MPM сейчас работает, есть два способа, первый — получить список модулей с помощью apachectrl (для CentOS):
Apachectl -t -D DUMP_MODULES
Это пример для Debian систем:
Apache2ctl -t -D DUMP_MODULES
Второй способ посмотреть подробную информацию о версии Apache. На CentOS:
Для смены MPM на некоторых ОС потребуется перекомпиляция apache, или установка соответствующего пакета apache (apache2-mpm-event, apache2-mpm-prefork, apache2-mpm-itk, apache2-mpm-worker).
В CentOS системах достаточно будет просто раскомментировать в файле /etc/sysconfig/httpd строку
HTTPD=/usr/sbin/httpd.worker
и перезагрузить apache…
HostnameLookups — это директива, которая включает reverse DNS запросы, в результате в логи, вместо IP адресов будут попадать dns хосты. Эта директива будет тормозить запрос, пока не последует ответа от DNS сервера.
Поэтому в конфиг файле эта директива должна быть отключена: HostnameLookups Off
Если вам так необходимы dns адреса — пользуйтесь logresolve.
Так же убедитесь в том, что в директивах Allow from и Deny from использовались IP адреса, так как apache будет делать два запроса, чтобы убедиться в том что клиент — тот за кого себя выдает.
Если вам не Требуется, чтобы Apache
автоматически распознавал язык каждого посетителя и выдавал страницы на со ответствующем языке, то отключите данный модуль: a2dismod negotiation
Если опция FollowSymLinks включена для какой-то директории, то сервер будет следовать по символическим ссылкам данной директории. Если эта опция отключена, то Apache будет делать много лишних системных запросов. Держите ее включенной.
Если опция SymLinksIfOwnerMatch включена для какой-то директории, то сервер будет следовать по символическим ссылкам только в случае совпадения владельца этой директории и файла/директории куда ссылается эта ссылка. Это говорит о том что SymLinksIfOwnerMatch делает больше запросов, поэтому отключайте ее.
Если директива AllowOverride не установлена в ‘None’, Apache будет искать файл.htaccess в каждой директории, которую он посещает. Вот пример:
DocumentRoot /var/www/html
Если будет запрошен файл /index.php, Apache будет пытаться открыть файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess, что увеличивает время запроса. Поэтому, если вам необходим этот файл только для одной директории, то включайте эту директиву только для нее:
DocumentRoot /var/www/html
Данная директива устанавливает максимальное количество запросов, которое будет обслуживать Apache. MaxCliets не должно быть много. Значение выставляется большим, чтобы обрабатывать одновременно много запросов, а меньшим для снижения потребления памяти!
Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум). Если значение MinSpareServers слишком маленькое и неожиданно приходит много запросов, apache вынужден будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers слишком велико, apache будет сильно нагружать систему этими процессами, даже если количество клиентов минимально.
Устанавливайте такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом, что будет говорить о том что MinSpareServers слишком мало.
Эта директива устанавливает количество запросов, которое сможет обработать один дочерний процесс, прежде чем он будет завершен. По умолчанию там установлено 0, что может привести к утечке памяти, поэтому установите туда, например, 4096…
Apache — популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать — перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов:).
Другой способ — просто увеличить производительность сервера — поставить более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.
Apache — модульная программа, большая часть функций которой реализуется в модулях. При этом эти модули могут быть как вкомпилированы, так и собраны в виде DSO — динамических библиотеках. Большинство современных дистрибутивов поставляет apache с набором DSO, так что не нужные модули можно легко отключить без перекомпиляции.
Запускайте apache только с необходимыми модулями, чтобы уменьшить потребление памяти. Если вы решили скомпилировать apache самостоятельно, то либо тщательно подходите к выбору списка модулей, которые вы включите, либо компилируйте их как DSO используя apxs в apache1 и apxs2 в apache2. Для того чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Apache со статически скомпилированными модулями будет потреблять чуть меньше памяти, однако вам придется каждый раз его перекомпилировать для изменения списка модулей.
В apache каждый запрос обрабатывается в своем процессе или потоке. При компиляции apache позволяет выбирать один из нескольким MPM (Multi-processing module), которые отвечают за прослушивание портов, прием запросов и раздачу этих запросов дочерним процессам или потокам, в которых эти запросы будут обработаны.
Выбор MPM зависит от нескольких факторов, таких как наличие поддержки потоков в ОС, количества свободной памяти, а также требований стабильности и безопасности.
Если безопасность очень важна, следует выбрать peruser MPM, пожертвовав производительностью.
Если важна именно производительность, то выбор ограничивается двумя mpm: prefork и worker.
Worker
- поточный MPM, т.е. в нем каждый запрос обслуживается в отдельном потоке одного из дочерних процессов. Потоки — более легкие для ОС объекты, чем процессы, они более эффективно используют память и переключения контекста для них происходят быстрее. Однако, из-за того что каждый поток имеет доступ ко всей памяти процесса, worker mpm более подвержен сбоям: сбой одного потока может повлечь падение всего процесса, в котором находился этот поток (именно поэтому worker mpm запускает несколько дочерних процессов с несколькими потоками в каждом).
Perfork
- mpm использует несколько дочерних процессов, каждый дочерний процесс обрабатывает одно подключение. Из-за того что процесс — более тяжелая структура, он использует немного больше ресурсов, зато он менее подвержен сбоям — обработка каждого отдельного запроса не зависит от других процессов.
К сожалению, для смены mpm требуется перекомпиляция apache. Тут проявляют свои достоинства source-based дистрибутивы: вы можете легко перекомпилировать apache и все зависимые от него пакеты, не превратив систему в свалку. Бинарные дистрибутивы выходят из этой ситуации по-разному. Например в RHEL в apache rpm находится сразу две версии apache — с worker и prefork mpm (prefork используется по умолчанию). Однако worker mpm не поддерживает php. Так что если вы хотите php и worker mpm вам придется компилировать его самостоятельно либо искать сторонние репозитории.
Директива HostnameLookups включает reverse DNS запросы, так что в логи будут попадать dns-хосты клиентов вместо ip-адресов. Разумеется, что это существенно замедляет обработку запроса, т.к. запрос не обрабатывается пока не будет получит ответ от DNS-сервера. Поэтому следите чтобы эта директива всегда была выключена (HostnameLookups Off), а если вам все-таки нужны dns-адреса, вы можете узнать их позже, прогнав лог в утилите logresolve (которая поставляется с apache).
Кроме того, следите чтобы в директивах Allow from и Deny From использовались ip-адреса а не доменные имена. Иначе apache будет делать два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за кого себя выдает.
Если директива AllowOverride не установлена в ‘None’, apache будет пытаться открыть.htaccess файлы в каждой директории которую он посещает и во всех директориях выше нее. Например:
DocumentRoot /var/www/html
Если будет запрошен /index.html, apache попытается открыть (и интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так что, если вам нужен.htaccess только для одной директории, разрешайте его только для нее:
DocumentRoot /var/www/html
Если для директории включена опция FollowSymLinks, сервер будет следовать по символическим ссылкам в этой директории. Если для директории включена опция SymLinksIfOwnerMatch, apache будет следовать по символическим ссылкам только если владелец файла или директории, на которую указывает эта ссылка совпадает с владельцем указанной директории. Так что при включенной опции SymLinksIfOwnerMatch apache делает больше системных запросов.
Кроме того, дополнительные системные запросы требуются когда FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. наиболее оптимальная ситуация для производительности — когда опция FollowSymlinks включена.
Старайтесь избегать content negotiaion.
Директива MaxClients устанавливает максимальное количество параллельных запросов, которые будет поддерживать сервер. Apache не будет порождать больше процессов/потоков чем MaxClients. Значение MaxClient не долно быть слишком маленьким (иначе много клиентов останутся необслуженными), но и не стоит устанавливать слишком большое количество — лучше не обслужить часть клиентов чем исчерпать все ресурсы, залезть в своп и умереть под нагрузкой. Хорошим может быть значение MaxClients = количество памяти выделенное под веб-сервер / максимальный размер порожденного процесса или потока. Для статических файлов apache использует около 2-3 Мб на процесс, для динамики (php, cgi) — зависит от скрипта, но обычно около 16-32 Мб.
Если сервер уже обслуживает MaxClients запросов, новые запросы попадут в очередь, размер которой устанавливается с помощью директивы ListenBacklog.
Т.к. создание потока, и особенно процесса — дорогая операция, apache создает их заранее. Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум). Если значение MinSpareServers слишком маленькое и неожиданно приходит много запросов, apache вынужден будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers слишком велико, apache будет сильно нагружать систему этими процессами, даже если количество клиентов минимально.
Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом. Это — сигнал того что MinSpareServers слишком мало.
Директива MaxRequestsPerChild устанавливает сколько запросов может обработать один дочерний процесс/поток прежде чем он будет завершен. По умолчанию значение этой директивы установлено в 0, что означает что однажды созданный процесс/поток не будет завершен никогда (ну кроме случаев остановки сервера или краха этого процесса/потока). Рекомендую установить MaxRequestsPerChild равное какому-нибудь достаточно большому числу (несколько тысяч). Это не создаст излишней нагрузки, связаной с тем что apache будет вынужден создавать новые дочерние процессы, в то же время это поможет избавиться от проблем с утечкой памяти в дочерних процессах (что очень возможно например если вы используете нестабильную версию php).
KeepAlive позволяет делать несколько запросов в одном TCP-подключении. Это особенно полезно для html-страниц с большим количеством изображений. Если KeepAlive установлен в Off, то для самой страницы и для каждого изображения будет создано отдельное подключение (которое нужно будет обработать master-процессу), что плохо и для сервера и для клиента. Так что для подобных случаев рекомендуется устанавливать KeepAlive в On. Для других применений (например для download-сервера) KeepAlive может быть бесполезен и даже вреден, т.к. при включенном KeepAlive сервер закрывает соединение не сразу, а ждет KeepAliveTimeout секунд нового запроса. Для того чтобы процессы не висели слишком долго в бесполезном ожидании, устанавливайте KeepAliveTimeout достаточно малым, около 5-10 секунд обычно достаточно.
HTTP-сжатие было определено в стандарте HTTP/1.1, и сейчас все современные клиентские программы и практически все сервера его поддерживают. Сервер может отдавать ответ в gzip или deflate, а клиентская программа незаметно для пользователя разжимает данные. Это уменьшает количество передаваемого трафика (до 75%), но конечно же повышает использование процессора.
Однако если ваш сервер посещает много клиентов с медленным подключение, сжатие может снизить нагрузку с вашего сервера из-за того что сервер сможет быстрее передать сжатый ответ и освободить ресурсы, занятые дочерним процессом. Особенно сильно этот эффект может быть заметен если у вас быстрый процессор, но мало памяти.
Кеширование конфигурируется директивами модуля mod_deflate. Имейте в виду, что не следует устанавливать степень сжатия gzip более 4-5 — это потребует существенно большего времени CPU, а эффект будет достаточно невелик. Ну и разумеется не нужно пытаться сжать изображения в jpg, gif и png, музыку, видео файлы и все другие бинарные файлы, которые уже и так хорошо сжаты.
