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

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

Допустим, ты имеешь в своем распоряжении веб-сервер, на котором крутится более-менее посещаемый динамический веб-сайт, созданный на базе одной из PHP'шных CMS. В общем, самая типичная для современного рунета ситуация. Сайт развивается, растет, посетителей становится все больше, и ты начинаешь замечать постепенно возрастающие задержки в скорости отдачи контента. Простейшие замеры показывают, что сервер уже не справляется с возложенными на него задачами, и в голову начинают закрадываться порочные мысли о покупке железа (аренде более мощного виртуального сервера). Но спешить не стоит, в большинстве случаев ситуацию легко обратить в свою пользу.

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

  • Оптимизация Apache;
  • Оптимизация PHP;
  • Установка eAccelerator;
  • Установка Nginx в качестве фронт-энда;
  • Установка Memcached;
  • Клиентская оптимизация.
 

Оптимизация Apache

Корневой компонент большинства современных веб-сайтов — это, конечно же, Apache. Он зарекомендовал себя как наиболее функциональный, стабильный и удобный в использовании HTTP-сервер, который можно использовать как для обслуживания домашней веб-страницы, так и для высоконагруженных корпоративных интернет-проектов. Одна проблема: Apache — очень тяжелое приложение, жадное до ресурсов сервера.

И это должно быть учтено при его настройке. Вот список рекомендаций, которые лучше выполнять при подготовке HTTP-сервера к работе:

  • Львиная доля функционала Apache вынесена в загружаемые модули, которые можно активировать или отключить путем редактирования конфигурационного файла (директива LoadModule). Хорошей практикой является тотальное отключение всех неиспользуемых модулей, что позволит повысить производительность сервера и сохранить оперативную память.
  • Apache обрабатывает каждый новый запрос в собственном потоке исполнения и позволяет использовать разные подходы для выполнения этой операции. Если ты собирал Apache2 из исходников, то мог заметить, что в опциях сборки присутствует возможность выбора так называемого MPM. Это и есть модуль мульти-процессинга (Multi-processing module), используемый для распараллеливания HTTP-сервера.

Всего их существует три:

  1. prefork — классический MPM, реализующий модель мульти-процессинга, используемую в Apache 1.3. Каждый поток обрабатывается в отдельном процессе. Не самый производительный вариант, но наиболее стабильный. Используется по умолчанию.
  2. worker — MPM, основанный на потоках. Сервер порождает несколько процессов, по несколько потоков в каждом. Один запрос — один поток. Производительнее prefork, но менее стабилен.
  3. event — событийный MPM. Вместо потоков запросы обрабатываются, используя событийную модель, похожую на ту, что применяется в nginx. Наиболее производительный MPM, но и наименее стабильный (находится в экспериментальной стадии разработки).

Многие дистрибутивы позволяют устанавливать разные варианты Apache, различающиеся используемым MPM, их легко можно найти в репозитории по запросу «apache2-mpm».

  • Apache позволяет контролировать максимальное количество порождаемых потоков с помощью опции MaxClients. Не стоит устанавливать ее значение слишком большим, иначе в определенный момент сервер исчерпает всю оперативную память, начнет свопить, и необслуженными останутся гораздо больше клиентов, чем было бы при задании жесткого ограничения. Оптимальным считается значение, равное количеству памяти, доступной Apache, поделенное на максимальный размер порожденного потока (проверяется с помощью ps или top).
  • Как и многие другие HTTP-серверы, Apache позволяет контролировать длительность удержания соединений типа keep-alive, используемых для передачи нескольких запросов/ответов в рамках одного соединения. Keep-alive позволяет экономить ресурсы сервера, не вынуждая его создавать отдельный поток на каждую картинку, CSS и прочие элементы страницы. Однако слишком долго такое соединение держать открытым не стоит, потому как на это тоже уходят ресурсы. Хорошим значением опции KeepAliveTimeout будет 5-10 секунд, причем, если все зависимые компоненты страницы отдаются клиенту отдельными серверами, а текущий сервер используется только для отдачи HTML/PHP, необходимость поддержки keep-alive отпадает вовсе, и значение опции KeepAlive лучше установить в Off.
  • Apache не любит сжатие. Если ты решил увеличить скорость отдачи страниц с помощью сжатия, то имей в виду, что, скорее всего, оно создаст еще большую нагрузку на сервер. Если же сжатие действительно необходимо (например, для мобильного портала, основной поток клиентов которого использует канал GPRS), то устанавливай коэффициент сжатия минимальным, это приведет лишь к незначительному росту объема результирующих данных, зато позволит существенно сэкономить ресурсы сервера.
 

Оптимизация PHP

Зачастую наибольшая нагрузка создается вовсе не HTTP-сервером, а интерпретатором языка программирования, используемого для создания динамического содержимого веб-сайта. Сегодня наиболее популярным языком для серверного веб-скриптинга является PHP, поэтому именно ему мы уделим внимание в нашей статье. Открываем файл /etc/php5/ apache2/php.ini (путь для Ubuntu, в других дистрибутивах может быть иным) и редактируем следующие строки:

  • memory_limit — лимит на съедаемую при генерации веб-страницы память. Перед изменением этого параметра рекомендуется выполнить соответствующие замеры и основывать значение уже на их результатах.
  • display_errors = Off, error_log = /var/log/php — перенаправлять сообщения об ошибках в log-файл. Включай этот параметр тогда, когда все скрипты будут полностью отлажены.
  • upload_max_filesize и post_max_size — максимальный размер загружаемых файлов и POST-запросов. Опять же, значение должно быть выбрано исходя из потребностей твоего веб-приложения.

Теперь можно закрыть файл и выполнить глубокую оптимизацию с помощью PHP-ускорителя.

 

Установка Eaccelerator

PHP — язык интерпретируемый. Это значит, что каждый раз, когда происходит вызов скрипта на этом языке, запускается PHP-интерпретатор, который проводит полный анализ исходного кода. Причем, если спустя секунду произойдет второй запуск того же скрипта, вся процедура будет повторена заново. Это нерациональное использование ресурсов, поэтому мы применим инструмент под названием eAccelerator, который скомпилирует исходные тексты PHP в двоичное представление, оптимизирует их и будет бережно хранить в оперативной памяти для более быстрого доступа. Благодаря только этому скорость обработки PHP-скриптов вырастет в десятки раз (подтверждено тестами).

Пакета eAccelerator нет в репозиториях популярных дистрибутивов, поэтому его придется собрать самостоятельно. Сначала устанавливаем необходимые для сборки утилиты:

$ sudo apt-get install php5-dev build-essential

Далее получаем исходные тексты eAccelerator:

$ 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
[PHP]
; Подключаем расширение
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"

 

Установка nginx

Будучи популярным, большой динамический веб-сайт может создать такую нагрузку на сервер, что 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

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
<html>
<body>
<!--# include virtual="/auth.php" -->
<!--# include virtual="/body.php" -->
</body>
</html>

Это ровно та же страница, код аутентификации которой вынесен в файл auth.php, а вся остальная часть — в body.php. Изюминка же заключается в том, что приведенный выше в четвертом шаге код кэширования ты помещаешь только во второй из этих файлов. Как результат вырисовывается следующая картина:

  1. Человек приходит на сайт в первый раз. Происходит запрос главной страницы веб-сайта к nginx.
  2. Сервер nginx запрашивает файл index.php у бэк-энда (Apache), встречает внутри него SSI-директивы и делает еще *2* запроса к бэк-энду (auth.php и body.php).
  3. Получив запросы, Apache запускает PHP-интерпретатор для обработки запрашиваемых файлов, в результате чего (кроме всего прочего) содержимое тяжелого файла body.php попадает в кэш memcached.
  4. Ответ возвращается nginx, который объединяет файлы в один index. php и отдает их клиенту.
  5. После этого на сайт приходит зарегистрированный участник, происходит запрос index.php у бэк-энда (хотя, скорее всего, он будет взят из кэша самого nginx), однако к Apache уйдет только запрос простого и легкого auth.php, тогда как body.php будет взят из кэша memcached.

Само собой разумеется, SSI необходимо активировать в конфигурационном файле nginx с помощью опции «ssi on», помещенной в секцию «location /». Стоит отметить, что блок auth.php также поддается кэшированию, но для этого придется присваивать всем зарегистрированным пользователям идентификатор, сохранять его в кукисах и использовать для генерации уникального ключа memcached.

 

Клиентская оптимизация

Эта статья посвящена серверной оптимизации веб-сайтов, однако было бы кощунством не рассказать и о клиентской части этого процесса. Поэтому мы кратко пробежимся по списку рекомендаций, направленных на минимизацию общего объема передаваемых данных:

  1. Используй gzip или deflate для сжатия страниц и данных. Для этого можно задействовать модули HTTP-серверов: ngx_http_gzip_module для nginx, mod_compress для lighttpd и mod_deflate для Apache.
  2. Используй упаковщики для оптимизации и удаления лишнего мусора из HTML и JavaScript (обычно они удаляют все комментарии и пробелы, заменяют имена на более короткие и т.д., например, web-optimizator, code.google.com/p/web-optimizator).
  3. Выноси CSS и JavaScript-код в отдельные файлы, тогда они смогут быть закэшированы браузером и применены к другим страницам (также их можно разместить на отдельном сервере, чтобы их загрузка происходила параллельно).
  4. Для более плавной и корректной загрузки страницы браузером размести загрузку CSS в начале страницы, а JavaScript — в конце.
  5. Не забывай устанавливать заголовки Expires и Cache-control, чтобы CSS и JavaScript могли быть закэшированы браузером.
  6. Не применяй JPG и PNG тогда, когда можно обойтись GIF (например, для мелких иконок).
 

Балансировка

Round robin DNS — один из самых простых видов балансировки нагрузки. Для ее реализации достаточно присвоить IP-адреса двух или более серверов одному доменному имени. Однако, есть и существенный минус: если один из серверов выйдет из строя, часть клиентов все равно будут отправлены к нему.

 

memcached

При наличии достаточно больших объемов памяти хорошей практикой будет запуск демона memcached с флагом '-L'. В результате демон заранее подготовит к использованию всю выделенную ему память. Это немного поднимет общую производительность работы memcached за счет исключения необходимости производить постоянные выделения памяти во время работы.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии