Быстрая оптимизация настроек веб сервера Apache и Nginx. Использование не слишком «долгих» KeepAlive

После ввода в строй динамического веб-сервера на базе apach + php + postgresql (да и на базе других систем тоже, если честно), вебмастер часто обнаруживает, что производительность системы начинает с большей или меньшей активностью стремиться к нулю, порой его достигая при наплывах посетителей. Стандартными действиями вебмастера при этом являются лихорадочное чтение документации, поиск в Интернете всяческих полезных советов, общение в форумах и прочие телодвижения, типичные для «компьютерного аврала». При этом очень часто находятся какие-то обрывки информации, ответы из серии «у меня заработало, почему у тебя не работает не знаю», противоречивые советы и ссылки на мегабайтные исходники, разбор которых грозит затянуться на несколько лет…

Поэтому ниже предпринята попытка в компактном виде изложить те вещи, которые наиболее значительно влияют на производительность сервера. Нельзя сказать, что этот список является полным и законченным, но он может послужить неплохой пищей для размышлений. А если у вас есть какие-то свои наработки и «идеи по поводу» — пишите автору, он постарается учесть их в следующей редакции этой статьи…

Настройка php

Настройка php, по большому счету, сводится к включению persistent connections и, соответственно, использованию pg_pconnect() вместо pg_connect() в скриптах. Для этого в файле php.ini надо указать pgsql.allow_persistent = on В некоторых форумах встречалась рекомендация установить еще и pgsql.auto_reset_persistent = on для определения «битых» соединений, но то ли «битые соединения» встречаются очень редко, то ли они проявляются как-то незаметно… Словом, этого можно и не делать. Ограничений по количеству соединений в php можно не устанавливать, оставив
pgsql.max_persistent = -1
pgsql.max_links = -1

Эффект от перехода на постоянные соединения очень заметен, особенно на посещаемых сайтах. Загрузка сразу падает процентов на двадцать-тридцать, а то и больше! Только не пугайтесь обнаруживая в top’е кучу postres’ов в состоянии sbwait…

Настройка postgresql

Настройка postgresql осуществляется с помощью редактирования файла postgresql.conf и последующего перезапуска постмастера. Несмотря на то, что некоторые параметры можно менять «на лету», практика показала, что полный перезапуск позволяет намного точнее и быстрее отследить влияние тех или иных изменений конфигурации на поведение системы в целом, так что имеет смысл использовать именно этот метод.

Настройка shared_buffers в postgres’е очень важна. Чем больше памяти ему выделено, тем больше данных он сможет использовать не обращаясь к диску. Но если памяти выделить слишком много, то другим процессам ее может не хватить и они будут использовать файл подкачки. Поэтому с настройкой этого параметра придется поэкспериментировать — помимо всего прочего, очень многое зависит от конкретики вашего сайта, в частности от того, насколько часто запрашиваются одни и те же данные. В качестве стартовой точки можно попробовать выделить postgres’у 40% памяти, если он работает на одной машине с веб-сервером, и 70%, если это выделенный сервер баз данных. Только не забудьте, что до того, как указывать количество памяти в файле postgresql.conf, вам надо настроить операционную систему, чтобы она разрешила эту память забрать, иначе postgresql просто не запустится, написав в лог, что не удалось получить требуемую память. О том как настроить выделение необходимой памяти в разных ОС подробно написано в документации postgresql. Эта память выделяется один раз при старте сервера.

Следующий полезный параметр — sort_mem. Эта память используется для сортировки полученных наборов данных, и большое ее количество полезно, если ваши запросы часто используют select … order by… Но с этим параметром надо быть очень осторожным — мало того, что указанное вами количество памяти выделяется каждому процессу, так оно еще и может выделяться несколько раз для сложных запросов! Так что с этим параметром тоже стоит «поиграть» — попробуйте изменять его значения в диапазоне, скажем, от 1 Мб до 128 Кб. Причем иногда результаты бывают парадоксальными — уменьшение памяти ведет к повышению производительности, по всей видимости, из-за создания множества маленьких временных файлов, которые операционная система успешно кеширует в свободной памяти.

Если задачи, выполняющиеся на сервере не являются критичными и возможная потеря нескольких записей при аварии вас не пугает, то стоит также отменить принудительную запись на диск результатов каждой транзакции. Делается это указанием fsync = false. При этом результаты ваших изменений будут хранится в памяти и записываться на диск целыми блоками, что позволит достаточно заметно увеличить производительность. Но, как было отмечено выше, если вдруг сервер «упадет», то результаты нескольких последних обновлений могут быть утеряны.

Очень сильно влияет на скорость работы грамотное индексирование таблиц. Про индексы можно писать (и уже написано) много, но основной принцип — индексировать надо те поля, которые используется для выборки данных (проверяются в where). Составные индексы (в которых используется несколько полей) работают, если отбор происходит с условием and, если используется or, то надо создавать несколько отдельных индексов.

Однако для маленьких таблиц (скажем, до 500 строк) перебор почти всегда оказывается быстрее, чем использование индексов. Тут можно применить маленькую хитрость: в postgresql.conf указать enable_seqscan = false (это запретит перебор для тех таблиц, у которых есть индексы) и удалить все индексы в маленьких таблицах (индексы, автоматически создаваемые для первичных ключей, можно удалить, используя drop constraint).

Неплохой выигрыш в производительности может дать и оптимизация самих sql запросов, особенно тех, которые используются чаще всего. Для того, чтобы их вычислить можно в скриптах перенумеровать все запросы и перед каждым вызовом pg_query() записывать в лог (или в таблицу) номер запроса. А потом просто проанализировать лог… Для того, чтобы посмотреть как будет выполняться запрос можно (нужно!) использовать команду explain. Учтите, что в некоторых случаях даже простое изменение порядка следования условий выборки в секции where может изменить план выполнения запроса!

В некоторых случаях может помочь и использование представлений (views). Дело в том, что при выдаче «обычного» sql запроса сервер его анализирует, создает план выполнения и потом выполняет. А если используется представление, то анализ и составление плана производится только при его создании. Если запросы выполняются часто, то сэкономленное время работы процессора может оказаться весьма заметным. Не говоря уже о том, что запросы в скриптах станут намного короче и нагляднее…

Практически во всех руководствах (и в документации postgresql) можно встретить рекомендации регулярно запускать vacuum analyze, для сжатия таблиц. Рекомендация правильная и полезная, но недостаточная. Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось «дырок» от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется, что может привести к проблемам на популярном сервере — начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в swap, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно.

Тут можно использовать следующий трюк — во время работы vacuum’а перенаправлять посетителей на страничку с пояснениями, что идет профилактика и сервер восстановит свою работу через несколько минут. При использовании веб-сервера apache это легко делается с помощью mod_rewrite: ваш оптимизирующий скрипт при запуске создает, а при окончании работы удаляет файл /home/site/optimizer.pid, а в apache включается mod_rewrite и указывается
rewritecond /home/site/optimizer.pid -f
rewriterule .* /optimization_message.html

Для того чтобы уменьшить время, в течение которого посетители не могут добраться до вашего сайта, можно перенаправлять посетителей только в то время, когда оптимизируются большие и частоиспользуемые таблицы, а остальные «чистить» паралльно с работой сайта. Если данные в базе обновляются очень часто, то можно, скажем, каждый час запускать vacuum analyze, а раз в сутки — vacuum full analyze. Как правило, «время недоступности» сервера при таком подходе можно сократить до одной-двух минут даже на очень больших сайтах.

Кроме того, надо учесть, что vacuum не оптимизирует индексы, поэтому после отработки vacuum full analyze стоит запускать еще и reindex.

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

Настройка apache

Конфигурационный файл apache, как правило, находится в /usr/local/apache/conf/httpd.conf, а заставить сервер его перечитать можно с помощью проргаммы /usr/local/apache/bin/apachectl.

Основной целью дальнейших рекомендаций является определение и ограничение количества «апачей», выполняющихся в каждый момент времени (предполагается, что сам сервер у вас уже настроен и работоспособен). Дело в том, что (условно) на каждого посетителя сайта «тратится» процесс apache, и каждый такой процесс расходует память и процессорное время. Поэтому если у вас будет слишком много запущенных серверов, то оперативной памяти не хватит, а использование swap’а сильно замедляет работу сайта. С другой стороны, если запущенных серверов мало, то при заходе пользователя будет тратиться время на создание нового процесса, что опять же приводит к задержкам и расходу процессорного времени.

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

Максимальное количество «апачей», которые могут быть запущены одновременно определяется параметром maxclients. Это число должно чуть-чуть превышать максимальное количество посетителей, которые могут в какой-то момент времени оказаться у вас на сайте. В то же время, если желающих к вам попасть много, а ресурсов сервера для их обслуживания не хватает, то излишне высокое число запущенных серверов только затормозит всю работу. Поэтому желательно установить какое-то разумное ограничение, скажем 150 или 200.

Время, в течение которого сервер ждет откликов от клиента определяется параметром timeout. Обрывы связи иногда случаются и если браузер посетителя обратился к вашему серверу, не получил ответа и послал повторный запрос (скажем, пользователь нажал reload), то у вас запустятся два «апача», причем один из них будет просто висеть и в течение указанного времени ждать, когда посетитель подтвердит свое желание посмотреть страничку. По умолчанию этот параметр установлен в 300 секунд, но значительно более эффективным оказалось понизить его до 30.

Включение поддержки keepalive может заметно облегчить жизнь. Дело в том, что в «обычном» режиме для передачи каждого файла клиенту требуется установить соединение, и если у вас на страничке, например, есть 10 картинок, то придется устанавливать и разрывать 10 соединений для их передачи. А в режиме keepalive сервер после передачи файла соединение не разрывает и последующие запросы от этого клиента обрабатывает, используя уже установленное соединение. Таким образом экономится время на установку и разрыв соединений, причем для популярных сайтов эта разница может быть очень заметна!

Для keepalive соединений, точно также как и для обычных, надо установить timeout с помощью параметра keepalivetimeout. Так как сервер, установивший соединение с клиентом, недоступен для других клиентов пока соединение не будет разорвано, слишком большое значение может привести к куче серверов, ничего не делающих и просто ждущих не захочет ли их клиент скачать еще что-нибудь. Причем в это же время толпа новых посетителей может обнаружить, что ваш сайт не отвечает, так как достигнуто максимальное число разрешенных «апачей»… Наиболее практичным значением параметра keepalivetimeout является что-то между десятью и двадцатью секундами.

Как известно, долгое использование какой-то программы может привести к «утечкам памяти» или каких-то других ресурсов. Чтобы избежать таких проблем есть два параметра: maxkeepaliverequests и maxrequestsperchild. Первый параметр отвечает за принудительное «убиение» процесса после обработки указанного числа keepalive запросов, а второй — после указанного числа «обычных» запросов. В принципе, на абсолютном большинстве систем утечек памяти быть не должно и эти параметры можно сделать достаточно большими — по несколько тысяч. Но на всякий случай последите за поведением сервера — не исключено, что «утечки» обнаружатся в какой-то из библиотек, которые вы используете. Удобнее всего двигаться «снизу вверх» — сначала установить значения небольшими, скажем, 100 и 50, а потом их увеличивать, наблюдая за поведением сервера.

Сегодня я расскажу о том, как сделать Apache немного быстрее. Кто-то спросит — «зачем?.. есть же более быстрые решения!»….
Таким товарищам я отвечу что да, есть, что они быстрее, например на одной жестяной банке я использую связку Apache+Nginx (даже писал об этом), можно использовать Nginx с модулем FastCGI.. И об этом я напишу, не в этой статье, но напишу..

Но сейчас речь пойдет о том, как сделать Apache немного быстрее, адекватнее и безопаснее. Картинка, тег «more» и пошла статья…

Модули в Apache

Первое, самое основное, что-то типа «спасибо-кэп» — 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

Подходящий MPM

В apache каждый запрос обрабатывается в своем процессе или потоке. При компиляции apache позволяет выбирать один из нескольким MPM (Multi-processing module), которые отвечают за прослушивание портов, прием запросов и раздачу этих запросов дочерним процессам или потокам, в которых эти запросы будут обработаны.

Если безопасность важна — выбирайте peruser MPM. Если важна производительность, то выбирайте prework или worker.

• Worker — поточный MPM, т.е. в нем каждый запрос обслуживается в отдельном потоке одного из дочерних процессов. Потоки — более легкие для ОС объекты, чем процессы, они более эффективно используют память и переключения контекста для них происходят быстрее. Однако, из-за того что каждый поток имеет доступ ко всей памяти процесса, worker mpm более подвержен сбоям: сбой одного потока может повлечь падение всего процесса, в котором находился этот поток (именно поэтому worker mpm запускает несколько дочерних процессов с несколькими потоками в каждом).
• Perfork — mpm использует несколько дочерних процессов, каждый дочерний процесс обрабатывает одно подключение. Из-за того что процесс — более тяжелая структура, он использует немного больше ресурсов, зато он менее подвержен сбоям — обработка каждого отдельного запроса не зависит от других процессов.

По мне так 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…

DNS запросы

HostnameLookups — это директива, которая включает reverse DNS запросы, в результате в логи, вместо IP адресов будут попадать dns хосты. Эта директива будет тормозить запрос, пока не последует ответа от DNS сервера.

Поэтому в конфиг файле эта директива должна быть отключена: HostnameLookups Off

Если вам так необходимы dns адреса — пользуйтесь logresolve.

Так же убедитесь в том, что в директивах Allow from и Deny from использовались IP адреса, так как apache будет делать два запроса, чтобы убедиться в том что клиент — тот за кого себя выдает.

Content Negotiation

Если вам не Требуется, чтобы Apache
автоматически распознавал язык каждого посетителя и выдавал страницы на со ответствующем языке, то отключите данный модуль: a2dismod negotiation

FollowSymLinks и SymLinksIfOwnerMatch

Если опция FollowSymLinks включена для какой-то директории, то сервер будет следовать по символическим ссылкам данной директории. Если эта опция отключена, то Apache будет делать много лишних системных запросов. Держите ее включенной.

Если опция SymLinksIfOwnerMatch включена для какой-то директории, то сервер будет следовать по символическим ссылкам только в случае совпадения владельца этой директории и файла/директории куда ссылается эта ссылка. Это говорит о том что SymLinksIfOwnerMatch делает больше запросов, поэтому отключайте ее.

AllowOverride

Если директива AllowOverride не установлена в ‘None’, Apache будет искать файл.htaccess в каждой директории, которую он посещает. Вот пример:

DocumentRoot /var/www/html AllowOverride all

Если будет запрошен файл /index.php, Apache будет пытаться открыть файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess, что увеличивает время запроса. Поэтому, если вам необходим этот файл только для одной директории, то включайте эту директиву только для нее:

DocumentRoot /var/www/html AllowOverride None AllowOverride all

MaxClients

Данная директива устанавливает максимальное количество запросов, которое будет обслуживать Apache. MaxCliets не должно быть много. Значение выставляется большим, чтобы обрабатывать одновременно много запросов, а меньшим для снижения потребления памяти!

MinSpareServers, MaxSpareServers, и StartServers

Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум). Если значение MinSpareServers слишком маленькое и неожиданно приходит много запросов, apache вынужден будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers слишком велико, apache будет сильно нагружать систему этими процессами, даже если количество клиентов минимально.

Устанавливайте такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом, что будет говорить о том что MinSpareServers слишком мало.

MaxRequestsPerChild

Эта директива устанавливает количество запросов, которое сможет обработать один дочерний процесс, прежде чем он будет завершен. По умолчанию там установлено 0, что может привести к утечке памяти, поэтому установите туда, например, 4096…

Введение

По данным Netcraft, Apache — самый популярный веб-сервер в интернет, он
обслуживает множество серверов и сайтов. Часто возникает необходимость
увеличить производительность веб-сервера. Наверное лучший способ это
сделать — перейти к схеме frontend+backend, но это может потребовать
достаточно серьезных изменений в приложении (например, у вас наверняка
отвалятся всяческие индикаторы прогресса аплоада файлов).

Другой способ — просто увеличить производительность сервера — поставить
более быстрый процессор и больше памяти.

Однако и первое и второе требует много времени и ресурсов, так что на
первое время можно попробовать ускорить apache путем оптимизации его
конфигурации. Существуют оптимизации, которые можно применить только
при пересборке apache, другие же можно применять без перекомпиляции
сервера.

Загружайте только необходимые модули

Apache — модульная программа, бОльшая часть функций которой реализуется
в модулях. При этом эти модули могут быть как вкомпилированы, так и
собраны в виде DSO — динамических библиотеках. Большинство современных
дистрибутивов поставляет apache с набором DSO, так что не нужные модули
можно легко отключить без перекомпиляции.

Запускайте apache только с необходимыми модулями, чтобы уменьшить
потребление памяти. Если вы решили скомпилировать apache
самостоятельно, то либо тщательно подходите к выбору списка модулей,
которые вы включите, либо компилируйте их как DSO используя apxs в
apache1 и apxs2 в apache2. Для того чтобы отключить ненужные
DSO-модули, достаточно закомментировать лишние строчки LoadModule в
httpd.conf. Apache со статически скомпилированными модулями будет
потреблять чуть меньше памяти, однако вам придется каждый раз его
перекомпилировать для изменения списка модулей.

Выберете подходящий MPM

В 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 вам придется компилировать его самостоятельно либо искать
сторонние репозитории.

DNS lookup

Директива HostnameLookups включает reverse DNS запросы, так что в логи
будут попадать dns-хосты клиентов вместо ip-адресов. Разумеется, что
это существенно замедляет обработку запроса, т.к. запрос не
обрабатывается пока не будет получит ответ от DNS-сервера. Поэтому
следите чтобы эта директива всегда была выключена (HostnameLookups
Off), а если вам все-таки нужны dns-адреса, вы можете узнать их позже,
прогнав лог в утилите logresolve (которая поставляется с apache).

Кроме того, следите чтобы в директивах Allow from и Deny From
использовались ip-адреса а не доменные имена. Иначе apache будет делать
два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за
кого себя выдает.

AllowOverride

Если директива AllowOverride не установлена в ‘None’, apache будет
пытаться открыть.htaccess файлы в каждой директории которую он
посещает и во всех директориях выше нее. Например:

DocumentRoot /var/www/html

AllowOverride all

Если будет запрошен /index.html, apache попытается открыть (и
интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess,
и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так
что, если вам нужен.htaccess только для одной директории, разрешайте
его только для нее:

DocumentRoot /var/www/html

AllowOverride None


AllowOverride all

FollowSymLinks и SymLinksIfOwnerMatch

Если для директории включена опция FollowSymLinks, сервер будет
следовать по символическим ссылкам в этой директории. Если для
директории включена опция SymLinksIfOwnerMatch, apache будет следовать
по символическим ссылкам только если владелец файла или директории, на
которую указывает эта ссылка совпадает с владельцем указанной
директории. Так что при включенной опции SymLinksIfOwnerMatch apache
делает больше системных запросов.

Кроме того, дополнительные системные запросы требуются когда
FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. наиболее оптимальная ситуация для
производительности — когда опция FollowSymlinks включена.

Content Negotiatio

Старайтесь избегать content negotiaion.

MaxClients

Директива MaxClients устанавливает максимальное количество параллельных
запросов, которые будет поддерживать сервер. Apache не будет порождать
больше процессов/потоков чем MaxClients. Значение MaxClient не долно
быть слишком маленьким (иначе много клиентов останутся необслуженными),
но и не стоит устанавливать слишком большое количество — лучше не
обслужить часть клиентов чем исчерпать все ресурсы, залезть в своп и
умереть под нагрузкой. Хорошим может быть значение MaxClients =
количество памяти выделенное под веб-сервер / максимальный размер
порожденного процесса или потока. Для статических файлов apache
использует около 2-3 Мб на процесс, для динамики (php, cgi) — зависит
от скрипта, но обычно около 16-32 Мб.

Вы можете прикинуть примерный размер посмотрев на колонку rss в выводе
`ps -ylC httpd —sort:rss`

Если сервер уже обслуживает MaxClients запросов, новые запросы попадут
в очередь, размер которой устанавливается с помощью директивы
ListenBacklog.

MinSpareServers, MaxSpareServers, и StartServers

Т.к. создание потока, и особенно процесса — дорогая операция, apache
создает их заранее. Директивы MaxSpareServers и MinSpareServers
устанавливают как много процессов/потоков должны ожидать в готовности
принять запрос (максимум и минимум). Если значение MinSpareServers
слишком маленькое и неожиданно приходит много запросов, apache вынужден
будет создавать много новых процессов/потоков, что создаст
дополнительную нагрузку в этой стрессовой ситуации. С другой стороны,
если MaxSpareServers слишком велико, apache будет сильно нагружать
систему этими процессами, даже если количество клиентов минимально.

Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы
apache не создавал более 4 процессов/потоков в секунду. Если он создаст
более 4, в ErrorLog будет помещено сообщение об этом. Это — сигнал того
что MinSpareServers слишком мало.

MaxRequestsPerChild

Директива MaxRequestsPerChild устанавливает сколько запросов может
обработать один дочерний процесс/поток прежде чем он будет завершен. По
умолчанию значение этой директивы установлено в 0, что означает что
однажды созданный процесс/поток не будет завершен никогда (ну кроме
случаев остановки сервера или краха этого процесса/потока). Рекомендую
установить MaxRequestsPerChild равное какому-нибудь достаточно большому
числу (несколько тысяч). Это не создаст излишней нагрузки, связаной с
тем что apache будет вынужден создавать новые дочерние процессы, в то
же время это поможет избавиться от проблем с утечкой памяти в дочерних
процессах (что очень возможно например если вы используете нестабильную
версию php).

KeepAlive и KeepAliveTimeout

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, музыку, видео файлы и все другие бинарные файлы, которые уже и
так хорошо сжаты.

Кеширование на стороне клиента

Не забывайте устанавливать Expires заголовки на статические файлы (см.
модуль mod_expires). Если файл не изменяется, то его всегда следует
попробовать закешировать на клиенте. Тогда у клиента будут быстрее
загружаться страницы, а сервер освободится от лишних запросов.

Apache — популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать — перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов:).
Другой способ — просто увеличить производительность сервера — поставить более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.

Загружайте только необходимые модули

Apache — модульная программа, большая часть функций которой реализуется в модулях. При этом эти модули могут быть как вкомпилированы, так и собраны в виде DSO — динамических библиотеках. Большинство современных дистрибутивов поставляет apache с набором DSO, так что не нужные модули можно легко отключить без перекомпиляции.
Запускайте apache только с необходимыми модулями, чтобы уменьшить потребление памяти. Если вы решили скомпилировать apache самостоятельно, то либо тщательно подходите к выбору списка модулей, которые вы включите, либо компилируйте их как DSO используя apxs в apache1 и apxs2 в apache2. Для того чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Apache со статически скомпилированными модулями будет потреблять чуть меньше памяти, однако вам придется каждый раз его перекомпилировать для изменения списка модулей.

Выберете подходящий MPM

В 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 вам придется компилировать его самостоятельно либо искать сторонние репозитории.

DNS lookup

Директива HostnameLookups включает reverse DNS запросы, так что в логи будут попадать dns-хосты клиентов вместо ip-адресов. Разумеется, что это существенно замедляет обработку запроса, т.к. запрос не обрабатывается пока не будет получит ответ от DNS-сервера. Поэтому следите чтобы эта директива всегда была выключена (HostnameLookups Off), а если вам все-таки нужны dns-адреса, вы можете узнать их позже, прогнав лог в утилите logresolve (которая поставляется с apache).
Кроме того, следите чтобы в директивах Allow from и Deny From использовались ip-адреса а не доменные имена. Иначе apache будет делать два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за кого себя выдает.

AllowOverride

Если директива AllowOverride не установлена в ‘None’, apache будет пытаться открыть.htaccess файлы в каждой директории которую он посещает и во всех директориях выше нее. Например:

DocumentRoot /var/www/html AllowOverride all

Если будет запрошен /index.html, apache попытается открыть (и интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так что, если вам нужен.htaccess только для одной директории, разрешайте его только для нее:

DocumentRoot /var/www/html AllowOverride None AllowOverride all

FollowSymLinks и SymLinksIfOwnerMatch

Если для директории включена опция FollowSymLinks, сервер будет следовать по символическим ссылкам в этой директории. Если для директории включена опция SymLinksIfOwnerMatch, apache будет следовать по символическим ссылкам только если владелец файла или директории, на которую указывает эта ссылка совпадает с владельцем указанной директории. Так что при включенной опции SymLinksIfOwnerMatch apache делает больше системных запросов.
Кроме того, дополнительные системные запросы требуются когда FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. наиболее оптимальная ситуация для производительности — когда опция FollowSymlinks включена.

Content Negotiatio

Старайтесь избегать content negotiaion.

MaxClients

Директива MaxClients устанавливает максимальное количество параллельных запросов, которые будет поддерживать сервер. Apache не будет порождать больше процессов/потоков чем MaxClients. Значение MaxClient не долно быть слишком маленьким (иначе много клиентов останутся необслуженными), но и не стоит устанавливать слишком большое количество — лучше не обслужить часть клиентов чем исчерпать все ресурсы, залезть в своп и умереть под нагрузкой. Хорошим может быть значение MaxClients = количество памяти выделенное под веб-сервер / максимальный размер порожденного процесса или потока. Для статических файлов apache использует около 2-3 Мб на процесс, для динамики (php, cgi) — зависит от скрипта, но обычно около 16-32 Мб.

Если сервер уже обслуживает MaxClients запросов, новые запросы попадут в очередь, размер которой устанавливается с помощью директивы ListenBacklog.

MinSpareServers, MaxSpareServers, и StartServers

Т.к. создание потока, и особенно процесса — дорогая операция, apache создает их заранее. Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум). Если значение MinSpareServers слишком маленькое и неожиданно приходит много запросов, apache вынужден будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers слишком велико, apache будет сильно нагружать систему этими процессами, даже если количество клиентов минимально.
Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом. Это — сигнал того что MinSpareServers слишком мало.

MaxRequestsPerChild

Директива MaxRequestsPerChild устанавливает сколько запросов может обработать один дочерний процесс/поток прежде чем он будет завершен. По умолчанию значение этой директивы установлено в 0, что означает что однажды созданный процесс/поток не будет завершен никогда (ну кроме случаев остановки сервера или краха этого процесса/потока). Рекомендую установить MaxRequestsPerChild равное какому-нибудь достаточно большому числу (несколько тысяч). Это не создаст излишней нагрузки, связаной с тем что apache будет вынужден создавать новые дочерние процессы, в то же время это поможет избавиться от проблем с утечкой памяти в дочерних процессах (что очень возможно например если вы используете нестабильную версию php).

KeepAlive и KeepAliveTimeout

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, музыку, видео файлы и все другие бинарные файлы, которые уже и так хорошо сжаты.

Что замедляет работу Apache и как получить максимум от PHP

Серия контента:

Linux, Apache, MySQL и PHP (или Perl) служат основой для архитектуры LAMP для Web-приложений. Многие пакеты с открытыми кодами, базирующиеся на компонентах LAMP, доступны для решения целого ряда задач. Поскольку нагрузка на приложение возрастает, узкие места основной инфраструктуры становятся более явными, что выражается в замедлении реакции на запросы пользователей. В показано, как настроить систему Linux, и дано описание основ LAMP и измерения производительности. Эта статья сфокусирована на компонентах Web-сервера, как Apache, так и PHP.

Настройка Apache

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

Конфигурирование мультипроцессорных модулей

Приложение Apache является модульным, в том смысле, что вы легко можете добавлять и удалять его элементы. Эту модульную функциональность в ядре Apache -- управление сетевыми соединениями и отправку запросов -- обеспечивают мультипроцессорные модули (Multi-Processing Modules, MPM). Модули позволяют вам использовать thread"ы или даже перемещать Apache в другую операционную систему.

Одновременно может быть активен только один мультипроцессорный модуль и он должен быть скомпилирован статически при помощи --with-mpm=(worker|prefork|event) .

Традиционная модель "один процесс на запрос" назвается prefork . Более новая, модель с thread"ами, называемая worker , использует несколько процессов, каждый с несколькими thread"ами, для получения более высокой производительности при более низких накладных расходах. Наконец, event -- экспериментальный модуль, который содержит особые группы thread"ов для различных задач. Чтобы определить, какой мультипроцессорный модуль вы сейчас используете, выполните httpd -l .

Выбор мультипроцессорного модуля зависит от многих факторов. Отключение модуля event до тех пор, пока он имеет экспериментальный статус, -- это выбор между thread"ами и их отсутствием. Внешне кажется, что использовать thread лучше, чем использовать fork, если все основные модули являются безопасными thread"ами, включая все используемые PHP библиотеки. Prefork -- более безопасный выбор; если вы выбрали worker, вы должны провести тщательное тестирование. Рост производительности также зависит от входящих в дистрибутив библиотек и вашего оборудования.

Независимо от того, какой мультипроцессорный модуль вы выбрали, вы должны соответствующим образом сконфигурировать его. Вообще, конфигурирование модуля подразумевает определение, как Apache контролирует количество запущенных worker"ов, являются ли они thread"ами или процессами. В Листинге 1 показаны важные опции конфигурирования модуля prefork.

Листинг 1. Конфигурирование мультипроцессорного модуля prefork

В модуле prefork новый процесс создан при помощи запроса. Резервные процессы простаивают, чтобы общаться с поступающими запросами, что уменьшает время ожидания запуска. Предыдущая конфигурация запускает 50 процессов, как только стартует Web-сервер, и старается поддерживать в наличии от 10 до 20 простаивающих запущенных серверов. Жесткий лимит процессов определяется при помощи MaxClients . Даже если процесс может общаться с множеством последовательных запросов, Apache убивает процессы после 4,000 соединений, что уменьшает риск утечки памяти.

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

Выбор используемых значений подразумевает некий метод проб и ошибок. Наиболее важное значение -- MaxClients . Цель состоит в том, чтобы разрешить достаточное количество процессов worker или thread"ов, чтобы сервер не занимался исключительно свопингом. Если поступает больше запросов, чем может быть обработано, то по крайней мере те, которые поступили, обрабатываются; другие блокируются.

Если MaxClients слишком высок, все клиенты получают недостаточно высокий уровень сервиса, поскольку Web-сервер пробует выгрузить один процесс, чтобы позволить выполняться другому. Установка слишком низкого значения приводит к тому, что вы можете необоснованно отказать в обслуживании. Проверка количества процессов, запущенных в момент повышенной нагрузки, и анализ объема памяти, используемой всеми процессами Apache, дает вам хорошую идею относительно установки этого значения. Если вы устанавливаете значение MaxClients выше 256, вы должны установить то же значение для ServerLimit ; внимательно прочтите документацию по мультипроцессорным модулям, чтобы узнать о соответствующих предостережениях.

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

Эффективное применение опций и переопределений

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

Эти конфигурации имеют вид контейнеров в httpd.conf, например, определяет, что конфигурация обращается к местоположению на диске, или задает отсылку на путь, указанный в URL. В Листинге 2 показан контейнер Directory в действии.

Листинг 2. Контейнер Directory, применяемый к каталогу root

В Листинге 2 конфигурация, ограниченная тегами Directory и /Directory , применяется к данному каталогу и его содержимому -- в этом случае к каталогу root. Здесь тег AllowOverride определяет, что пользователям не разрешается отменять любые опции (более подробно об этом позже). Опция FollowSymLinks разрешена, что позволяет Apache видеть прошлые символьные линки для обслуживания запроса, даже если файл не входит в каталог, содержащий Web-файлы. Это означает, что если файл в вашем Web-каталоге является символьным линком на /etc/passwd, Web-сервер успешно обслужит файл, если поступит запрос. Использование -FollowSymLinks отключит эту возможность, и тот же самый запрос будет причиной возврата ошибки клиенту.

Последний сценарий -- повод для беспокойства на двух фронтах. Первый -- вопрос производительности. Если FollowSymLinks отключен, Apache должен проверять каждый компонент имени файла (каталоги и собственно файл), чтобы убедиться, что они не являются символьными линками. Это влечет дополнительные накладные расходы в форме нагрузки на диск. Сопутствующая опция FollowSymLinksIfOwnerMatch следует за символьным линком, если владелец файла тот же, что и владелец линка. Это оказывает такое же воздействие на производительность, как и отключение следования символьным линкам. Для наилучшей производительности используйте опции из .

Читатели, которых волнуют вопросы безопасности, уже должны быть обеспокоены. Безопасность -- всегда компромисс между функциональностью и риском. В этом случае функциональность -- это скорость, и риск предполагает неавторизованный доступ к файлам системы. Смягчающим фактором является то, что серверы приложений LAMP обычно предназначены для определенной функции, и пользователи не могут создавать потенциально опасные символьные линки. Если жизненно необходимо разрешить проверку символьной ссылки, вы можете разрешить это только в определенной области файловой системы, как показано в Листинге 3.

Листинг 3. Ограничение FollowSymLinks для каталога пользователя

В Листинге 3 любой каталог public_html в домашнем каталоге пользователя имеет опцию FollowSymLinks , отключенную для этого и всех вложенных каталогов.

Как вы видели, опции могут конфигурироваться на покаталожной основе через конфигурацию главного сервера. Пользователи могут самостоятельно отменить конфигурацию сервера (если администратором разрешено AllowOverrides), исключив из каталога файл.htaccess. Этот файл содержит дополнительные директивы сервера, которые загружаются и применяются к каждому запросу каталога, в котором содержится файл.htaccess. Несмотря на прежние рассуждения об отсутствии в системе пользователей, многие приложения LAMP используют эту функциональность для осуществления контроля доступа и для перезаписи URL, так что это целесообразно для понимания того, как это работает.

Несмотря на то, что утверждение AllowOverrides препятствует пользователям в совершении тех действий, которые вы хотите им запретить, Apache по-прежнему должен искать файл.htaccess, чтобы выяснить, нужно ли что-нибудь сделать. Родительский каталог может определить директивы, которые должны быть обработаны запросом дочернего каталога, что означает, что Apache должен также исследовать каждый компонент дерева каталогов, ведущий к запрашиваемому файлу. По понятным причинам это является причиной высокой дисковой активности по каждому запросу.

Самое простое решение -- не позволять любые переопределения, которые отменяют необходимость проверки Apache файла.htaccess. Любые специальные конфигурации затем помещаются непосредственно в httpd.conf. В Листинге 4 показано, что нужно добавить в httpd.conf, чтобы позволить проверку пароля для пользовательского каталога project, вместо того чтобы помещать информацию в файл.htaccess и надеяться на AllowOverrides .

Листинг 4. Перемещение конфигурации.htaccess в httpd.conf

Если конфигурация помещена в httpd.conf и AllowOverrides отключен, интенсивность использования диска может уменьшиться. Каталог пользователя project может не привлечь большого количества обращений, но учитывайте мощь этого метода применительно к сайту, работающему с большой нагрузкой.

Иногда невозможно исключить использование файлов.htaccess. Например, в Листинге 5, где выбор ограничен определенной частью файловой системы, возможность отмены также может быть ограничена.

Листинг 5. Ограничение проверки.htaccess

После того как вы выполните операции из Листинга 5, Apache все же ищет файлы.htaccess в родительском каталоге, но прекращает поиск в каталоге public_html, поскольку становится невозможным функционирование остальной части файловой системы. Например, если запрашивается файл /home/user/public_html/project/notes.html, то его успешное отображение произойдет только в том случае, если каталоги public_html и project будут найдены.

Уместно сделать одно последнее замечание относительно относящихся к отдельным каталогам конфигураций. Любой документ о настройке Apache дает указание запретить DNS lookup через директиву HostnameLookups off , поскольку попытки обратно разрешить соединения всех IP-адресов с вашим сервером -- излишняя трата ресурсов. Однако любые ограничения, базирующиеся на имени хоста, вынуждают Web-север выполнять обратный lookup на IP-адресе клиента и прямой lookup на основании результата проверки подлинности имени. Поэтому благоразумно избегать использования средств контроля доступа, базирующихся на имени хоста, и, когда они необходимы, проверять их, как описано.

Постоянные соединения

Когда клиент соединяется с Web-сервером, разрешается порождение множественных запросов по одному и тому же TCP-соединению, что уменьшает время ожидания, связанное с многократными соединениями. Это полезно, когда Web-страница содержит несколько изображений: клиент может запросить страницу и затем все изображения в течение одного соединения. Обратная сторона состоит в том, что процесс worker на сервере должен ожидать закрытия сеанса клиентом, прежде чем он сможет перейти к следующему запросу.

Apache позволяет вам определять, как будут обработаны постоянные соединения, называемые keepalives . KeepAlive 5 на глобальном уровне httpd.conf позволяет серверу обработать 5 запросов на соединение, прежде чем соединение будет насильственно прервано. Установка этого числа в 0 запретит использование постоянных соединений. KeepAliveTimeout , тоже на глобальном уровне, определяет, как долго Apache будет ожидать другого запроса, прежде чем сессия закроется.

Обработка постоянных соединений не является конфигурацией типа "один-размер-годится всем". Некоторые Web-сайты функционируют лучше, если keepalives запрещены (KeepAlive 0), и в некоторых случаях их включение может принести огромную пользу. Единственное решение -- попробовать оба варианта и выяснить все самостоятельно. Тем не менее разумно использовать низкий таймаут, например, 2 секунды, при помощи KeepAliveTimeout 2 , если вы разрешили keepalives. Это даст гарантии, что любой клиент, желающий сделать другой запрос, будет иметь достаточное количество времени, и что процессы worker не останутся без работы, пока будут ждать другого запроса, который может никогда не поступить.

Сжатие

Web-сервер может сжимать вывод, прежде чем он возвратить его клиенту. В результате уменьшается объем страницы, посылаемой по Интернету, за счет циклов CPU на Web-сервере. Для тех серверов, которые могут позволить себе высокую нагрузку на CPU, это отличный способ создания быстро загружаемых страниц — размер страницы может после сжатия уменьшиться втрое.

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

Настройка PHP

PHP -- движок, который запускает код приложений. Вы должны установить только модули, которые планируете использовать, и сконфигурировать ваш Web-сервер для использования PHP только для файлов скриптов (обычно те файлы, названия которых заканчиваются на.php) а не всех статических файлов.

Кеширование кода операции

Когда запрашивается скрипт PHP, PHP читает скрипт и собирает его в то, что называется код операции Zend , бинарное представление кода, который будет выполнен. Этот код операции затем выполняется движком PHP и теряется. Кэш кода операции сохраняет его и в следующий раз при запросе страницы вновь использует. Это экономит немало времени. Некоторые кэши кода операции доступны; я успешно использовал eAccelerator.

Инсталляция eAccelerator требует наличия в компьютере библиотек разработки PHP. Поскольку разные дистрибутивы Linux помещают файлы в разные места, получите инструкции по инсталляции непосредственно с Web-сайта eAccelerator"а (см. ссылку в разделе ). Также возможно, что ваш дистрибутив уже упаковал кэш кода операции, и вы должны просто установить соответствующий пакет.

Независимо от того, каким образом вы установили на своей системе eAccelerator, есть несколько вариантов конфигурации. Конфигурационным файлом обычно бывает /etc/php.d/eaccelerator.ini. eaccelerator.shm_size определяет размер кэша совместно используемой памяти, где хранятся скомпилированные скрипты. Значение измеряется в мегабайтах. Определение подходящего размера зависит от приложения. eAccelerator предоставляет скрипт для показа статуса кэша, который включает использование памяти; 64 мегабайта -- хорошее значение для начала (eaccelerator.shm_size="64"). Вы также можете настроить максимальный размер для shared memory, если выбранное вами значение не было принято. Добавьте kernel.shmmax=67108864 в /etc/sysctl.conf и запустите sysctl -p , чтобы настройки вступили в силу. Значение kernel.shmmax измеряется в байтах.

Если превышен объем выделяемой shared memory, eAccelerator должен удалить из памяти старые скрипты. По умолчанию это отключено; eaccelerator.shm_ttl = "60" устанавливает, что когда eAccelerator исчерпывает размер shared memory, любой скрипт, доступ к которому не был получен в течение 60 секунд, должен быть удален.

Другая популярная альтернатива eAccelerator -- Alternative PHP Cache (APC). Создатели Zend также имеют коммерческий кэш кода операции, включающий оптимизатор для дальнейшего повышения эффективности.

php.ini

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

Таблица 1. Параметры настройки php.ini, связанные с ресурсами

Размер этих значений обычно зависит от приложения. Если вы принимаете от пользователей большие файлы, max_input_time может быть увеличен или в php.ini, или путем его переопределения в коде. Подобным образом, для программ, потребляющих большое количество CPU или памяти могут потребоваться более высокие значения. Цель состоит в том, чтобы уменьшить воздействие "прожорливой" программы, поэтому глобальная отмена этих настроек не рекомендуется. Другое замечание относительно max_execution_time: это относится ко времени, затраченному CPU на процесс, а не к абсолютному времени. Таким образом, программа, совершающая большое количество вводов/выводов и небольшое количество вычислений, может выполняться намного дольше, чем max_execution_time . max_input_time также может быть больше, чем max_execution_time .

Количество записей, которые может сделать PHP, может настраиваться. В промышленной эксплуатации экономят место на диске, отменяя все журналы, кроме самых критических. Если журналы необходимы для диагностики проблем, вы можете вернуть то журналирование, которое необходимо. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR включает журналирование, достаточное для выявления проблем, но удаляет из скриптов лишнюю информацию.

Заключение

Эта статья сфокусирована на настройке Web-сервера, как Apache, так и PHP. С Apache главная идея состоит в том, чтобы исключить лишние проверки, которые должен делать Web-сервер, например, обработку файла.htaccess. Вы также должны настроить мультипроцесорный модуль (MPM), который позволит сбалансировать используемые системные ресурсы и простаивающие worker"ы для входящих запросов. Лучшее, что вы можете сделать для PHP, -- установить кэш кода операции. Наблюдение за несколькими параметрами настройки ресурсов также гарантирует, что скрипты не завладеют ресурсами и не замедлят работу системы.

Следующая, заключительная статья из этой серии рассмотрит настройку базы данных MySQL. Не теряйте настрой!