Не спасовать перед лавиной: Подготавливаем веб-сервер к высоким нагрузкам. Кеширование кода операции. Уменьшение интенсивности логирования
Как увеличить производительность сервера на ОС CentOS. Часть третья: Быстрая оптимизация настроек веб сервера.
В данной статье мы расскажем, как увеличить производительность сервера (выделенного или виртуального) на примере ОС CentOS с помощью быстрой оптимизации настроек веб сервера Nginx и Apache (httpd).
Материал ориентирован на пользователей с небольшим багажом знаний в области администрирования, мы рассмотрим самые простые, и в тоже время действенные, способы повышения производительности сервера. В этой статье мы не станем рассказывать о предназначении и описывать все его настройки, затронем лишь самые необходимые моменты. Статья актуальна для любой панели управления, поэтому разделения на панели делать не будем.
Оптимально работать с сервером по SSH, но если Вы испытываете сложности в работе с SSH - можете открывать файлы через менеджер файлов панели управления. (Инструкция по работе с SSH в первой части этой статьи)
Оптимизация настроек веб сервера Apache (httpd).
Конфигурационный файл веб сервера Apache находится по следующему пути:
/etc/httpd/conf/httpd.conf
В этом файле обязательно нужно настроить ограничения по количеству одновременно запущенных процессов веб сервера. Для этого найдите в нем строку MaxClients , блок должен выглядеть примерно так:
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 256
MaxRequestsPerChild 0
Maxclients необходимо высчитать, опираясь на количество оперативной памяти, установленной на Вашем сервере. Также следует учесть количество памяти, используемой одним процессом веб сервера. Узнать количество потребляемой памяти одним процессом веб сервера можете с помощью утилиты top , инструкция по использованию в нашей базе знаний.
Далее отсчитайте 2\3 от общего количества оперативной памяти Вашего сервера и разделите на количество памяти, потребляемой одним процессом веб сервера. Полученное число и будет оптимальное значение MaxClients.
Например, имеем сервер с 8 Гб оперативной памяти. 2\3 от 8 будет 5.3 Гб. Один процесс веб сервера обычно потребляет около 40 Мб памяти. Считаем 5300мб \ 40мб, получаем 132. Лучше округлять в меньшую сторону. Оставляем значение 130, в итоге блок конфигурационного файла должен иметь такой вид:
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 130
MaxRequestsPerChild 0
Также включите KeepAlive, для этого найдите в конфигурационном файле строку:
KeepAlive Off
Измените Off на On:
KeepAlive On
После внесения изменений перезагрузите веб сервер командой:
/etc/init.d/httpd restart
Service httpd restart
Оптимизация настроек веб сервера Nginx.
Конфигурационный файл веб сервера Nginx находится по следующему пути:
/etc/nginx/nginx.conf
В нем необходимо настроить количество процессов Nginx. Обычно данная настройка зависит от количества ядер процессора, которые доступны для Вашего сервера. За это отвечает директива worker_processes, в конфигурационном файле это выглядит так:
User apache;
pid /var/run/nginx.pid;
worker_processes 4;
Как видите, количество процессов Nginx настроено для 4х ядер процессора. Если Ваш сервер обрабатывает очень много соединений, можете увеличить это значение на половину, если установить большее значение - это будет в убыток производительности.
Worker_rlimit_nofile 65536;
events {
use epoll;
worker_connections 65536;
}
Это увеличит ограничения для Nginx по количеству обрабатываемых файлов и улучшит его работу. Если в Вашем конфигурационном файле уже прописаны worker_rlimit_nofile или worker_connections - удалите их, оставьте только блок, как на образце.
В итоге начало конф-го файла должно выглядеть таким образом:
User apache;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
worker_processes 4;
worker_rlimit_nofile 80000;
events {
use epoll;
worker_connections 65536;
}
http {
default_type application/octet-stream;
log_format main "$remote_addr - $remote_user [$time_local] "$request" "
"$status $body_bytes_sent "$http_referer" "
""$http_user_agent" "$http_x_forwarded_for"";
access_log /var/log/nginx/access.log main;
Access_log off;
(Просмотреть нагрузку на диск можете с помощью утилиты top)
Также Вы можете включить в Nginx Gzip сжатие. Это может ускорить загрузку Вашего сайта, а также это выгодно в seo продвижении, однако рекомендуем проверить скорость загрузки после включения Gzip, т.к. на сайты с большим количеством запросов это может повлиять негативно. Чтобы включить Gzip сжатие в Nginx , нужно добавить в секцию http { такой код:
Gzip on;
gzip_comp_level 5;
gzip_min_length 10240;
gzip_disable "msie6";
Добавьте этот код на следующей строке после http { Чтобы это выглядело так:
Use epoll;
worker_connections 65536;
}
http {
gzip on;
gzip_comp_level 5;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
gzip_disable "msie6";
include /etc/nginx/mime.types;
default_type application/octet-stream;
Если ниже в коде встречаются настройки Gzip - удалите их.
После завершения настройки, выполните перезагрузку Nginx командой:
/etc/init.d/nginx restart
Service nginx restart
С предыдущими материалами по оптимизации настроек сервера можете ознакомиться по ссылкам:
Если у Вас возникнут трудности в настройке и администрировании сервера - всегда можете обратиться в нашу службу технической поддержки.
Решил я опять заняться ускорением своих сайтов. Недавно , но толку от него в моем случае мало: у меня на сервере стоят быстрые SSD диски, что и так быстро по умолчанию. К тому же все эти плагины для кэширования имеют одну проблему: если у вас , то плагин не понимает этого и обычному пользователю начинает выдавать мобильный шаблон.
К тому же Google Page Speed тоже не находит разницы, включено у меня кэширование или нет. Так зачем тогда мне грузить сервер лишним плагином? Лучше попытаться настроить сервер, чтобы он работал быстрее, тогда и каждый сайт не нужно ускорять в отдельности.
Как ускорить сервер apache за 5 минут?
Но прежде чем начать ускорять сервер, проверим текущую скорость на примере этого сайта. Воспользуюсь вот этим тестом скорости - Web Page Test
Хм, тест показал, что сайт стал на 2 секунды быстрее, случайность это или закономерность? Но так или иначе, хуже не стало, а только лучше. Но все же общее время загрузки страницы пока очень большое, нужно попробовать еще ускорить ngnix, так как он принимает запросы. А как видно из графика, первый отклик сайта происходит АЖ через секунду! Так же на графике видно, что сервис gravatar сильно замедляет страницу. Я раньше отключал его, но без него все комментаторы становятся безликими.
СОВЕТ ВЕБМАСТЕРУ: Умение зарабатывать в интернете - это только пол дела, вторая половина - это умение ВЫГОДНО обналичивать электронные деньги. Вот список офшорных банковских карт, на которые можно выводить средства и потом снимать с них хрустящие купюры:
1. Payoneer - Самая популярная в мире платежная система для фрилансеров. Выдает карты, находится в США.
2. EpayService - Американская платежная система, очень популярна во многих странах, бесплатно дает карту MasterCard в EVRO для жителей СНГ и Европы.
3. Skrill - Единственная платежная система которая работает с криптовалютами и при этом выпускает бесплатные банковские карты MasterCard.
4. AdvCash - Офшорный банк находится в Белизе, можно открыть счет в долларах, евро, фунтах и рублях.
5. Payeer - Штаб квартира этой платежной системы находится в Грузии, тут так же можно открыть счет в долларах, евро и рублях.
| Домен RU - 99 руб Домен РФ - 99 руб |
Сегодня я расскажу о том, как сделать 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
Если будет запрошен файл /index.php, Apache будет пытаться открыть файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess, что увеличивает время запроса. Поэтому, если вам необходим этот файл только для одной директории, то включайте эту директиву только для нее:
DocumentRoot /var/www/html
MaxClients
Данная директива устанавливает максимальное количество запросов, которое будет обслуживать Apache. MaxCliets не должно быть много. Значение выставляется большим, чтобы обрабатывать одновременно много запросов, а меньшим для снижения потребления памяти!
MinSpareServers, MaxSpareServers, и StartServers
Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум). Если значение MinSpareServers слишком маленькое и неожиданно приходит много запросов, apache вынужден будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers слишком велико, apache будет сильно нагружать систему этими процессами, даже если количество клиентов минимально.
Устанавливайте такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом, что будет говорить о том что MinSpareServers слишком мало.
MaxRequestsPerChild
Эта директива устанавливает количество запросов, которое сможет обработать один дочерний процесс, прежде чем он будет завершен. По умолчанию там установлено 0, что может привести к утечке памяти, поэтому установите туда, например, 4096…
Вообще, если вы можете не поднимать Apache , не делайте этого. Задумайтесь, может ли нужные вам задачи выполнять lighttpd или thttpd . Эти веб-серверы могут оказаться весьма кстати в ситуациях, где системных ресурсов на всех не хватает, а работать должно. Ещё раз повторюсь: речь идёт о тех ситуациях, когда функциональности этих продуктов будет достаточно для выполнения поставленных задач (кстати, lighttpd умеет работать с PHP ). В тех ситуациях, где без Apache ну просто никак не обойтись, всё равно обычно можно освободить немало системных ресурсов, перенаправив запросы к статическому контенту (JavaScript, графика) от Apache к легковесному HTTP-серверу. Наибольшей проблемой Apache является его большой аппетит к оперативной памяти. В этой статье я рассмотрю методы, помогающие ускорить работу и снизить объёмы занимаемой им памяти:
Загрузка меньшего количества модулей
Первым делом необходимо избавиться загрузки от ненужных модулей. Просмотрите конфиг-файлы и определите, какие модули у вас загружаются. Все ли загружаемые модули вам нужны? Найдите то, что не используется и отключите нафиг, этим вы сэкономите какое-то количество памяти.
Обработка меньшего числа параллельных запросов
Чем большему количеству процессов Apache разрешено запускаться одновременно, тем больше одновременных запросов он сможет обработать. Увеличивая это число, вы тем самым увеличиваете и объём памяти, отдаваемой под Apache . Воспользовавшись top, можно увидеть, что каждый процесс Apache занимает совсем немножко памяти, поскольку используются разделяемые библиотеки. В Debian 5 с Apache 2 по умолчанию используется такая конфигурация:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0
Директива StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. Директивы MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache . Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. Директива MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. Фактически, директива MaxClients и определяет максимально-допустимое число дочерних процессов Apache ,запущенных одновременно. Директива MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache , прежде чем завершить своё существование. Если значение этой директивы установлено равным нулю, то процесс не будет «истекать».
Для своего домашнего сервера, с соответствующими нуждами, я исправил конфигурацию на следующую:
StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300
Конечно же, приведённая выше конфигурация совершенно не годится для использования на высокозагруженных серверах, но для дома, на мой взгляд — самое оно.
Циркуляция процессов
Как можно было заметить, я изменил значение директивы MaxRequestsPerChild . Ограничив таким образом время жизни дочерних процессов количеством обработанных запросов, можно избежать случайных утечек памяти, вызванных криво-написанными скриптами.
Использование не слишком «долгих» KeepAlive
KeepAlive — это метод поддержки постоянного соединения между клиентом и сервером. Изначально протокол HTTP разрабатывался как не ориентированный на постоянные соединения. То есть, когда веб-страница отправляется клиенту, все её части (картинки, фреймы, JavaScript) передаются с использованием различных, отдельно устанавливаемых соединений. С появлением KeepAlive , у браузеров появилась возможность запрашивать постоянное соединение и, установив его, загружать данные, используя одно установленное соединение. Такой способ даёт неслабый прирост производительности. Однако Apache по умолчанию использует слишком большой таймаут перед закрытием соединения, равный 15-ти секундам. Это значит, что после того, как был отдан весь контент клиенту, запросившему KeepAlive , дочерний процесс ещё 15 секунд будет находиться в ожидании входящих запросов. Многовато, однако. Лучше уменьшить этот таймаут до 2-3 секунд.
KeepAliveTimeout 2
Уменьшение таймаута
Как вариант, можно уменьшить значение директивы TimeOut , которая определяет время ожидания завершения отдельных запросов. По умолчанию её значение равно 300 , быть может, в вашем случае будет иметь смысл это значение уменьшить/увеличить. Я лично пока оставил как есть.
Уменьшение интенсивности логирования
На пути к увеличению производительности сервера можно попробовать снизить интенсивность ведения протоколов. Модули, такие как mod_rewrite , могут писать в лог отладочную информацию, и если она вам не нужна — отключайте её вывод.
Отключение разрешения имён хостов
На мой взгляд, нет никакой необходимости в том, чтобы выполнять обратное преобразование IP-адресов в имена хостов. Если они уж так сильно вам необходимы при анализе логов, то можно определять их на стадии анализа, а не в процессе работы сервера. За разрешение имён хостов отвечает директива HostnameLookups , которая, вообще-то, по умолчанию и установлена в Off , однако проверьте это, если действительно считаете необходимым отключить преобразование.
HostnameLookups Off
Отключение использования.htaccess
Обработка файлов .htaccess выполняется Apache каждый раз при запросе данных. Мало того, что Apache должен загрузить этот файл, так ещё немало времени и ресурсов уходит на его обработку. Взгляните на ваш веб-сервер и пересмотрите необходимость в использовании файлов .htaccess . Если вам нужны различные настройки для разных каталогов, может быть реально будет их вынести в основной файл конфигурации сервера? А отключить обработку .htaccess можно директивой в конфигурации сервера.