+7 707 858 58 37
help@vpsadm.ru
Как сократить время ответа сервера? WordPress, Joomla, DLE — оптимизация для информационных сайтов на CMS и… дорвеев

Содержание

Наиболее частая задача, с которой ко мне обращаются клиенты — это оптимизация сервера для работы информационных сайтов на WordPress. Да и не только на WordPress, но на ней 90% сайтов.  Не менее часто обращаются люди, которым нужно оптимизировать сервер для быстрой работы интернет-магазинов. Это история отдельная, ибо там есть особенности.  И которая тоже когда-нибудь выйдет на страницах моего блога.  Так вот, это, можно сказать, стало уже типовой задачей.  Поэтому я решил подробно описать что такое оптимизация сервера и как это  происходит.  Какие возможности и настройки при этом затрагиваются.  Каковы причины, из-за которых возникает необходимость в оптимизации. С них, пожалуй, и начнём.

Зачем нужна оптимизация сервера? Наиболее частые причины

Вообще тут могут быть сотни различных вариантов, но это если рассматривать в подробностях. Я этого делать не буду, ибо почти все они в 90% случаев сводятся к следующим вариантам:

Хостер блокирует сайт за нагрузку, за превышение лимитов

Типичная картина первая: сайт разместили на обычном виртуальном хостинге и в какой-то момент по мере развития сайта и роста его посещаемости закономерно возникают предъявы от хостинга о том, что «уважаемый, а вы знаете, ваш сайт-де создаёт нагрузку на хостинг, превышает все установленные лимиты в дцать попугаев? Примите меры, разберитесь, покуда мы его не заблокировали». Такие вести вы можете получить совершенно внезапно от хостера, в лучшем случае. В терминальной стадии все может быть плачевней — ваш сайт хостер сразу просто блокирует за превышение нагрузки и пишет об этом уже по факту свершившегося.

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

SEO-специалисты, оптимизаторы рекомендуют добиться хорошей оценки в Google Pagespeed Insights

Типичная картина вторая: кто-то где-то как-то вам поведал о том, что сайт плохо растет в поиске если у него долгое время отклика. Мол, гугл имеет православный инструмент Pagespeed Insights, и если сайт не набирает достаточное количество попугаев в гугловой оценке, то будет у него все плохо, и вообще это чуть ли не единственная причина всех проблем с продвижением сайта. А вот если гугл покажет зелень — то все будет огонь, сайт взлетит в топы как ракета.

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

Вкратце — этот инструмент НЕ ВЛИЯЕТ ни на что сам по себе. Имеет значение время отклика сайта. Если оно более 2 сек — есть смысл оптимизировать.  Время отклика можно увидеть там же, если раскрыть подробности по пункту «Сократите время ответа сервера».  Я же предпочитаю смотреть его через отладчик браузера.  Так же стоит знать, что многие сайты из топов имеют оценку «ниже плинтуса» — по 20-40 баллов, но это им не мешает сидеть в топах.  И с другой стороны, сайт может выдавать зелень — 90 попугаев, но быть «ниже плинтуса» уже в выдаче.   Сайт может иметь хорошую оценку, но открываться по 3-5 секунд. Или иметь 20-40 баллов — и летать за 0,3-0,5 секунд. Так что логику гугла и тех сеошников тут не уловить. Гугл предоставил неплохой инструмент, но не стоит доводить до маразма. Ориентироваться ли на его показания? Конечно! Но без фанатизма.  И без завышенных ожиданий.

Сервер «падает» от большой посещаемости сайтов

Чуть менее типичная картина третья ( может быть и продолжением и дополнением первой, второй, или обеих):
Сайт имеет приличную посещаемость от 10000 уников в сутки ( хотя может быть и меньше) и есть проблема со временем открытия страниц. Сначала в часы пик, а потом и вообще постоянно. При этом время открытия страниц дольше 1-2 секунд. Сайт может перестать расти или начать падать.

Все три вышеизложенные ситуации — это в 90% случаев то, с чем приходят клиенты обращаясь за оптимизацией настроек софта, аудитом или переносом сайтов. И в том случае, если ваши сайты уже работают на выделенном или виртуальном сервере, то это можно решить оптимизацией настроек софта. Если же сайт(ы) на виртуальном хостинге, то оптимальное решение подобной проблемы чаще всего действительно в переносе на VPS. Во втором случае часто можно даже ничего не делать с настройками, достаточно бывает только переноса на сервер с настройками по-умолчанию. Возможно позже и упрёшься в необходимость опттмизации, а возможно и нет.

Что происходит при этом и почему сервер не держит нагрузку?

Итак, для начала разберём почему могут быть подобные трудности. Нагрузка на сервер может возникать по трем наиболее частым причинам:

  1.  У вас действительно очень посещаемый сайт и софт при стандартных настройках начинает захлебываться. Появляются лаги, некоторые или все страницы открываются дольше, особенно в часы пик.
  2. Вторая причина — это поисковые боты. Особенно если большое количество страниц — то при посещениях индексирующих ботов могут появиться проблемы с производительностью. Это может быть как самостоятельная причина, даже когда на сайте относительно небольшой трафик, так и в совокупности с первым случаем — и люди и боты. Определить это можно по логам вебсервера — access лог можно проанализировать и это сразу будет видно.
  3. Паразитный трафик. Это может быть обычный тупой брутфорс(перебор паролей) на админки сайтов, может быть попытка атаки на xmlrpc, а может быть банальный парсинг контента с вашего сайта.

Так ли необходима оптимизация под Google Pagespeed Insights?

Теперь стоит ещё раз остановиться на ситуации второй — когда вам нужна оптимизация ради оценки Гугла, якобы для продвижения сайта. На самом деле это миф, по большей части. Ибо пока сайт открывается быстрей 1-2 секунд — это МГНОВЕННО! И это практически не влияет на продвижение. Проблемы действительно могут быть, если сайт грузится дольше одной-двух секунд. Тогда это в самом деле может ухудшать поведенческие факторы, и влиять на SEO. Пруфы.

Как решить рекомендацию гугла  «Сократите время ответа сервера»?

Тем не менее, Гугл считает, что сайт недостаточно быстр, если TTFB более 0.2 секунды (200 ms). Такой загрузки можно добиться обычно только лишь кэшированием, и на этом остановлюсь чуть подробнее далее.

Но без кэширования норма времени генерации страниц сервером для того же wordpress обычно в пределах 0.5-1 сек. На очень быстром сервере с дефолтным шаблоном и php 7 пустой вордпресс будет показывать что-то около 0.3-0.5 секунд.
Если же в вашем случае это ощутимо дольше, то скорей всего можно комплексной оптимизацией настроек софта на сервере добиться более быстрой работы сайтов.

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

Какой софт на сервере обеспечивает работу сайта?

Прежде всего надо говорить об nginx. В большинстве случаев он и так уже стоит. Он обрабатывает все входящие запросы, и делает это очень легко и быстро. Второй компонент это — обработчик PHP. Это чаще всего apache. Как универсальный обработчик он стал стандартом де-факто практически у любых хостеров. Апач — прекрасный софт, как раз в силу своей универсальности.

Но он не выдерживает конкуренции с режимом php-fpm там, где появляется нагрузка. Он как раз чаще всего и является узким местом в производительности системы. Это решается подбором более производительного вашем случае режима работы и/или подбором настроек. (подробней о режимах работы и связках вебсервера  — компоненты nginx, apache, php-fpm, php-cgi)

Но режим имеет значение при ооочень больших нагрузках. Сотни тысяч посещений в сутки. Хотя, иногда и при десятках килоуников могут быть проблемы. Надо понимать, что php-fpm не прибавляет скорости. Он даёт лишь производительность.

Что это такое? Это значит, что он позволяет быстрее обрабатывать запросы при больших нагрузках. Там, где появляется большой трафик — апач начинает захлебываться, потреблять больше ресурсов. И там для  быстрой загрузки страниц возникает потребность увеличивать ресурсы сервера, переходить на более мощные тарифы или серверы.  Php-fpm же может держать бОльшие нагрузки даже на минимальных аппаратных конфигурациях.

Какую нагрузку может держать сервер для WordPress? Как расчитать мощность сервера?

Если в цифрах — то php-fpm примерно в  3-5 раз производительней apache. Это не значит, что он будет быстрей отдавать страницы, но.   К примеру, возмем дешевый VPS с 1 GB памяти и 1 CPU. Возьмем типовой сайт на wordpress.  Без кэширования, сайт на apache при этих ресурсах будет работать с минимальным временем отклика примерно до посещаемости 2-3 тысячи посетителей в сутки. Там конечно еще имеет значение количество хитов, но в среднем из практики цифры примерно такие. (Кейс — как я оптимизировал сайты на недорогом VPS )

Свыше 3к суточного трафика  у wordpress на апаче на таком VPS начнутся тормоза.  Особенно в часы пик.  Часто эта проблема решается кэширующими плагинами.  С ними можно говорить уже о 5-10к трафика при такой конфигурации. Если же сайт на этих ресурсах запустить в режиме nginx+php-fpm, то он будет откликаться максимально быстро даже при 10-20к трафика.  Если поставить кэширующий плагин  — можно еще получить запас прочности в 2-3 раза — до 30к трафика.

И наконец, если использовать серверное кэширование nginx, на таком VPS можно держать сотни тысяч посещений 🙂

Настройка сайтов в режиме nginx+PHP-FPM

К примеру, любая из популярных CMS из заголовка статьи гораздо лучше держит нагрузку в режиме nginx+php-fpm. У меня почти все сайты на wordpress, так я только в таком режиме их и запускаю. Типовая конфигурация для wp имеет примерно такой вид:

server {
server_name vpsadm.ru www.vpsadm.ru;
charset off;
index index.html index.php;
disable_symlinks if_not_owner from=$root_path;
include /etc/nginx/vhosts-includes/*.conf;
include /etc/nginx/vhosts-resources/vpsadm.ru/*.conf;
access_log /var/www/httpd-logs/vpsadm.ru.access.log;
error_log /var/www/httpd-logs/vpsadm.ru.error.log notice;
set $root_path /var/www/user/data/www/vpsadm.ru;
root $root_path;
location / {
try_files $uri $uri/ /index.php?$args;
location ~ [^/]\.ph(p\d*|tml)$ {
try_files /does_not_exists @php;
}
}
location @php {
fastcgi_index index.php;
fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f webmaster@vpsadm.ru";
fastcgi_pass unix:/var/www/php-fpm/vpsadm.sock;
fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$;
try_files $uri =404;
include fastcgi_params;
}
listen *:80;
}

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

try_files $uri $uri/ /index.php?$args;

Панель этого не умеет, по крайней мере пока. Именно она обеспечивает корректную работу ЧПУ, и заменяет привычный файл .htaccess, используемый в Apache. А вот в VestaCP есть шаблоны конфигов под работу популярных CMS в этом режиме.
Joomla тоже будет работать с аналогичным конфигом в связке nginx+php-fpm. А в случае с DLE все выглядит чуть сложнее:

Конфиг ЧПУ для DLE в режиме Nginx+PHP-FPM

Впрочем, ДЛЕ крайне редко нуждается в такой оптимизации, ибо сама CMS легкая и быстрая, да ещё и внутренний кэш имеет.

Но большой трафик способен нагрузить абсолютно любые, даже самые лёгкие и быстрые CMS. Все меры, которые я опишу дальше, основаны на кэшировании.

Основа оптимизации всего и вся — кэширование

Это единственный принцип, который даёт ощутимый эффект к производительности в работе любого серверного софта, и в том или ином виде он применяется на всех уровнях стека LAMP/LEMP(классически аббревиатура обозначает Linux Apache Mysql PHP, но сейчас уже давно стандартом де-факто стало использование nginx+apachе/php-fpm+mysql).

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

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

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

Оптимизация и ускорение исполнения PHP-кода

С этим обычно связаны самые большие накладные расходы в работе CMS. Чтобы это было понятней вам, мне придется объяснить что такое язык PHP.

Дело в том, что языки программирования делятся на компилируемые и интерпретируемые. К первым относится например C++ и его дедушка C(си), на котором написано больше всего софта в мире. Это значит, что код однажды переводится в машинный язык и в таком виде остаётся, это и есть готовая программа. Поэтому он выполняется очень быстро — сразу в процессор, грубо говоря. PHP же, и многие другие языки, которые используются ныне для веб-разработки (python, js, ruby) относятся к языкам интерпретируемым или скриптовым. Это значит, что программа представляет собой набор команд и исполняется последовательно, «на лету».

Это даёт больше гибкости и удобства в разработке, но оказывается сильно медленней и требует гораздо больше ресурсов.

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

66 — это не много.  Чаще всего при работе с wordpress запросов около сотни. В случае с интернет-магазинами — может  быть и 200-300.

Обращение к PHP при этом производится к одному скрипту, но тому для получения результата нужно чтобы выполнились десятки или сотни других скриптов.  В случае с wordpress — обычно это index.php. И каждый из таких скриптов выполняется аналогично — последовательно и на лету. Это уже совсем дебри, но я, пожалуй, покажу вам, как это выглядит изнутри:

Для загрузки одной страницы веб-сервер исполняет 82 скрипта самого wordpress и плагинов  на этом сайте.  У меня не влез в один экран список вызовов скриптов, который я вытащил с помощью ядерного отладчика strace.  Но должно быть отчетливо видно, что все эти скрипты  от index.php до footer.php были исполнены в одну секунду  «17:22:59» и время исполнения составило  около 0,3 секунд.  0,304571, если быть точным 🙂

Обычно лазить туда системным отладчиком нет необходимости,  это время можно увидеть через отладчик браузера — это многим известный TTFB:

О нём же и говорит гугл в своей многим непонятной рекомендации о сокращении ответа сервера. Примерно соответствует, верно? Откуда взялись еще 80 милисекунд?  А это время, затраченное вебсервером nginx на «общение»  с обработчиком php и сборку html-страницы. Как видите, на фоне исполнения PHP он молниеносен. Это действительно так.  В этом легко убедиться, если исключить всю работу php и mysql, оставив отдачу страницы одному только Nginx:

Тут видим всё же не 0,08 сек, а чуть больше — 0,11. Чем объяснить? Я не знаю, а копаться еще и в системных вызовах nginx у меня желания нет 🙂 Тут  на таких малых цифрах может быть всё что угодно — может просто  скачки нагрузки на оборудование, а может быть во время обработки PHP nginx не всё время просерает ждёт, а делает что-то ещё параллельно. Зная его и восхищаясь этим крутым веб-сервером, я подозреваю что так и есть — и эти 0,03 сек никуда не теряются, а лишь накладываются  на время исполнения PHP. Ну да ладно.  На последнем скрине — это идеальный вариант отдачи страницы, и о нем будет речь чуть дальше.

Оптимизация исполнения PHP кода CMS с помощью акселераторов opcache, xcache, APC

А пока вернемся к PHP.  С некоторых пор научились сохранять частично или полностью результат выполнения скриптов. Так называемая прекомпиляция. Это не полноценная компиляция, потому что PHP в принципе не может быть скомпилирован. И в любой момент что-то где-то может измениться во входных данных, в коде, и тогда уже этот сохраненный результат будет не валидным, т.е. неправильным. Потребуется исполнение кода заново. Вот за реализацию этого механизма отвечают специальные модули (расширения) языка PHP, называемые акселераторами. Их есть несколько разных, некоторые из них уже устарели, но все они используют один и тот же принцип кэширования. На тему акселераторов в разных версиях PHP есть на хабре хорошая статья, с наглядными графиками.

Впервые я с этим столкнулся когда всюду использовалась версия PHP 5.3. Я стал использовать это в виде расширения APC, и это стало довольно таки прорывной вещью для меня и проекта, над которым я тогда работал. Начиная с версии 5.5 обычно используется opcache, и говорят он вроде как встроен. Но на самом деле не всегда. Обычно это дополнительное расширение, которое нужно доустанавливать.  С установкой проблем нет, его можно легко включить в том же ISPmanager в разделе «Расширения PHP». В случае если вы не юзаете панель управления, то оно ставится  с помощью yum (centos) или apt-get (ubuntu, debian).  Что-то вроде:

yum install php-opcache

Иногда достаточно одной лишь установки, если у вас один  небольшой сайт на простенькой CMS. И чаще бывает так, что акселератор opcache установлен, но работает неэффективно, ибо по-умолчанию ему выделено недостаточно памяти.

Как проверить установлен ли opcache или другой акселератор PHP?

Обычно из консоли можно просто просмотром версии PHP, комадной php -v:

Но то что он установлен ещё не гарантирует, что он задействован на вашем сайте. При проверке таким образом можно точно сказать что он оптимизирует ваши сайты, если на сервере установлена лишь одна версия PHP.  Кроме этого при проверке таким способом срабатывает PHP-CLI — интерфейс командной строки. Но расширение может быть не подключено для режима PHP, на котором работает сайт — для apache, например.

Во-первых, он может быть установлен не для той версии PHP, которая используется для сайта.  Как на 100% убедиться, что он задействован? Исполнить проверку с помощью функции phpinfo().  Этот метод (описывал тут ) позволяет со 100% точностью определить все настройки PHP для вашего сайта.

Но и это ещё не всё.  Дело в том, что opcache может не работать, если PHP запущен в режиме CGI. Почему — вдаваться в подробности не буду. Просто потому, что такие особенности у этого режима.  Недаром он самый низкопроизводительный.  Если вы хотите чтобы opcache работал, то нужно запускать сайт в режиме модуля apache или php-fpm.

Как посмотреть настройки и эффективность работы opcache?

Для этого можно добавить в корень сайта файлик opcache.php с таким кодом.  Затем, при обращении по адресу site.com/opcache.php можно будет увидеть статистику работы акселератора:

Чаще всего вы увидите аналогичную картину. Это значит что акселератору не хватает памяти. Кэшируется лишь часть скриптов.  Соответственно, те, что не закэшированы всякий раз исполняются полностью, что снижает производительность веб-сервера.  Там же можно посмотреть список закэшированных скриптов и прочие настройки расширения.   Эффективность работы можно увидеть на вкладке hits.

В данном случае казалось бы эффективность не сильно снижена, что и отражает данная статистика. Hits  это попадания — т.е. выполнение кэшированных скриптов, которые выполняются гораздо быстрей.  Misses — пропуски, т.е скриптов в кэше нет. В данном случае мимо кэша идёт всего лишь 0,7% скриптов.  Но тут надо понимать, что в эти 222 тысячи миссов может попадать тот самый скрипт, который требует больше памяти и выполняется по 5 секунд 🙂  Гораздо эффективней акселератор будет работать, если у вас статистика использования памяти имеет такой вид:

А статистика исполнения скриптов из кэша примерно такая, или еще лучше:

В данном случае opcache настроен «на грани» ибо память как видите забита почти вся, осталось 16 байт 🙂 Такая ювелирность связана с небольшим количеством памяти на VPS, я подсчитал чтобы ровно столько сколько нужно использовалось и не килобайтом больше…  На самом деле нет.  Просто я не заглядывал туда давно, и эти копейки там уже особо роли не играют, а значения 128 и 256 это стандартные «айтишные» числа — степень двойки, и «ювелирная точность» просто совпадение. Вряд ли у меня там упускается и не попадает в кэш что-то критичное. Вот, а в случае с клиентом, с которого взяты первые три скрина — увеличение памяти повлияло ощутимо.   Там нормальные настройки opcache ускорили сайт примерно с 2 сек до 1,3.

Какое ускорение и прирост производительности даёт opcache?

Тут  не угадаешь. Обычно от 30 до 100% ускоряет. Иногда больше, иногда меньше.   Но в целом примерно такая картина —  наличие и отлаженная работа акселератора ускоряет отклик страниц в 1,5-2 раза

Где и какие изменить настройки opcache?

Нужно искать файлик opcache.ini где-то в /etc/. В разных системах и разных версиях PHP он может называться по-разному — 20-opcache.ini например, быть в /etc/php5/apache2/conf.d/opcache.ini или в /etc/php/php.d/20-opcache.ini. А иногда даже в /opt/remi/php70/etc/php/php.d/2o-opcache.ini, как например при использовании ISPmanager 5 и настройке opcache для альтернативных версий PHP. Имеет он примерно такой вид:


zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1
opcache.max_accelerated_files=7963
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist ; (comment this out in your dev environment): 
opcache.revalidate_freq=0
opcache.validate_timestamps=0

Итак, для оптимизации требуется подобрать количество памяти в мегабайтах, в очевидном параметре opcache.memory_consumption, также стоит изменить и opcache.max_accelerated_files — количество прекомпилированных скриптов. Нужное вам количество можно подобрать поглядывая на третью вкладку scripts в статистике opcache.  Увеличивайте, пока количество кэшированных скриптов при работе сайтов не станет меньше чем указанное значение. Точно так же подбирайте.

 

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

Смысл в отключении валидации файлов скриптов на изменения. Кэшер всякий раз проверяет изменился ли скрипт, прежде чем использовать кэшированную версию. Это дополнительные ресурсы и время. Отключение этой валидации позволяет добавить еще процентов 20-30 к производительности выполнения кода. Причем, вам необязательно что-то реально разрабатывать чтобы столкнуться с проблемами. Элементарная настройка шаблона или плагинов через панель управления того же wordpress может глючить. Посему, не используйте эти настройки. О них очень легко забыть и потом биться в истерике пару часов, пока вспомните почему не работают настройки и не появляются изменения 😀 Проверено.

 

Внимание!
После изменения любых настроек, здесь и далее, необходимо перезапускать сервисы (службы) которые вы настраиваете. Обычно это делается с помощью одного из вариантов:

systemctl restart service_name  #новые OS, например centos 7

или

service service_name restart #новые debian  или ubuntu

или такой вариант, который работает в старых версиях OS (centos 6, debian 6, ubuntu 12.04, etc):

/etc/init.d/service_name restart

вместо service_name нужно подставить имя настраивемой службы:  nginx, mysql(d), apache2/httpd, php5-fpm/php-fpm/php-fpm70 — они могут иметь какие-то такие названия. К примеру, после настройки opcache вам нужно сделать рестарт apache — значит это будет httpd в centos или apache2 в deb-системах  

Оптимизация настроек xcache

Фухх. Это только opcache. Есть еще apc, который уже устарел, и после версии 5.4 больше не используется. Хотя и есть костыли для обратного портирования даже на php 7, но юзать их тот еще гемор. Да и смысла в этом обычно нет.  А вот Xcache в принципе заслуживает внимания. Просто потому что он по эффективности почти не уступает opcache (см. график с хабра выше). Но в них настройки сводятся все к тем же принципам — увеличение памяти и количества скриптов.  В Xcache еще нужно подбирать count — количество пулов в зависимости от количества ядер и/или процессоров в системе.  Но останавливаться на этом сильно не буду. Покажу лишь как выглядит его статистика до и после оптимизации, бо недавно делал и скрины недалеко:

Это работа неоптимизированного акселератора.  Всего 16 мегабайт памяти.

А вот так он работает после настройки:

Тут была сделана оптимизация под четырехядерный процессор. Как видите появились пулы, и все они стали заполняться данными. Под которые понадобилось более 512 мегабайт.

 

Настройка пулов PHP-FPM

При использовании PHP-FPM не стоит оставлять ему конфиг по-умолчанию. Дело в том, что он с ним работает нестабильно и непонятно потребляет ресурсы.  У fpm, кстати, довольно редко, но случаются странные зависания, выяснить причину которых практически невозможно. Ну по крайней мере я за 4 года работы с этим софтом способов не нашел.  Зато на сотнях серверов опытным путём нашел,  что при использовании режима dynamic FPM то чаще всего и ведёт себя неадекватно.  Поэтому конфиг пула я делаю примерно таким:


pm = ondemand

pm.max_children = 10

pm.max_requests = 500

Вот это три самые важные параметра, а все остальные можно оставить по-умолчанию.  Первое режим.   Всего там могут быть три варианта  — кроме указанного еще static и dynamic есть. По умолчанию стоит именно dynamic и он самый нестабильный из всех возможных. Static — более стабильный, но ресурсоёмкий. Ибо он сразу запускает все процессы и выделяет на них память, поэтому с количеством процессов в таком режиме нужно быть очень осторожным.  Ondemand самый удобный режим. Он работает так же стабильно как статик, но не жрет ресурсы. Как только ему нужны еще процессы — он их запускает. Не нужны — процессы умирают.

Далее,  максимальное количество процессов, которые могут быть запущены — pm.max_children.  Я обычно ставлю в зависимости от мощности сервера.  Примерно 10-15 процессов на каждые  2 Gb памяти.

pm.max_requests  —  это количество обработанных процессом  запросов (выполненных скриптов), после чего процесс будет перезапущен. Позволяет избегать зависаний и утечек памяти.

Этот конфиг по умолчанию находится где-то в /etc/php-fpm.d/www.conf в centos, и в /etc/php5/fpm/pool.d/www.conf в deb-based системах (debian, ubuntu). Но это, как всегда, не точно 🙂  Во-первых, у вас сайты и пулы могут быть запущены под другим юзером. Тогда вместо www.conf нужный файлик будет именован как username.conf. Соответственно пулов и конфигов может быть несколько, они могут запускаться параллельно. А во-вторых, у вас может быть использоваться php альтернативной версии, и тогда нужно искать конфигурации пулов в другом месте. В каком — лучше всего смотреть через phpinfo().

Очистка любого конфига от примеров и комментариев, документации

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

Сделать это можно так:

cat /etc/php/php-fpm.d/www.conf|grep -v  '^;\|^$'

Это означает «вывести файл на консоль без пустых строк и строк, начинающихся с точки с запятой».   Можно сразу подготовить «чистую» конфигурацию для дальнейшей работы:


mv /etc/php/php-fpm.d/www.conf  /root/www.conf_orig cat /root/www.conf_orig |grep -v  '^;\|^$' > /etc/php/php-fpm.d/www.conf

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

Соответственно вариант будет таким:

cat /etc/httpd/conf/httpd.conf|grep -v '^#\|^$'

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

 

Базовые настройки PHP под нагрузку и тяжелые скрипты

Пулы и акселерация это хорошо.  Но кроме этого часто есть необходимость настроить глобальную конфигурацию самого PHP. Это делается через файлик php.ini.   В нем есть несколько наиболее важных параметров, без изменения коих часто бывает невозможно запустить тяжелые долговыполняющиеся скрипты.  Это более распостраненные настройки, обычно разработчики приложений и сайтов и сами знают о них.

Максимальное время исполнения скрипта.  К примеру, вы заливаете на дорвей миллион ключей из файла через какой-то веб-интерфейс.

По-умолчанию:

max_execution_time = 30

Это в секундах. Лучше добавить  сюда как минимум ноль, установив в 300. А иногда надо даже 600.

Максимальный объем памяти для выполнения одного (1!) скрипта.

memory_limit = 128M

По-умолчанию оно установлено в 128 мегабайт. Я недаром заострил внимание что речь идет лишь об одном скрипте. Помните сколько скриптов исполняется при запросе одной страницы? Это значит, что если у вас какое-то простое приложение, то обычно не нужно большое количество памяти для одного скрипта. И если приложение ее требует, то это повод задуматься о том, что что-то не так в коде. Но когда речь идет об импорте данных, это ситуация нормальная. Просто задавайте больший объем, перезапускайте apache и пробуйте еще раз. Увеличивать рекомендую с шагом в x2, обычно 256-512-1024 — ну просто для удобства используют эти числа.

Кроме этих параметров есть и другие, например максимальный объем загружаемого файла:

post_max_size = 8M
upload_max_filesize = 10M

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

В принципе больше особо никаких настроек тут не требуется.  Ну если вы настраиваете сервере с нуля, без панели, то может понадобиться включение  short_open_tag  и чего нибудь типа max_input_vars.

Оптимизация настроек производительности  apache (httpd)

Почему я пишу apache(httpd)? Потому что в rpm-based системах (centos, rhel, fedora)  сам apache нигде не фигурирует. Он там называется httpd. В deb-based системах это именно apache, причем apache2. Ну это не относится непосредственно к оптимизации, просто это следует знать, чтобы не потратить кучу времени на поиск конфигов и сервиса.

Соответственно конфигурации их будут где-то в /etc/apache2/apache2.conf и /etc/httpd/httpd.conf.

Оптимизация apache сводится к настройке количества процессов и запросов.  По аналогии с вышеописанными пулами PHP-FPM.

Однако в apache кроме этого есть разные режимы работы — prefork, worker, event. В 98% случаев у вас будет именно первый.

И его конфигурация имеет примерно такой вид:



StartServers 5
MinSpareServers 2
MaxSpareServers 4
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 250

 

Этим в принципе оптимизация apache и исчерпывается. Ну иногда еще есть смысл настроить таймауты и KeepAlive, но в случае с обычными сайтами скорей  всего оно не влияет ни на что. А вот вышеуказанные настройки влияют на распределение и использование ресурсов.

StartServers — количество процессов запускаемых при старте Apache

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

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

ServerLimit и MaxClients — максимальное количество одновременных соединений. Если указать их слишком большим, то при атаке или большом трафике есть риск, что апач ляжет пытаясь принять много соединений, но не успевая их обработать. И нужно понимать, что такое одновременные соединения. Это значит что пользователи одновременно в одну и ту же секунду нажали ссылку. 256 соединений могут образовать примерно 1-2 тысячи человек, находящихся на сайте онлайн. Таким образом, если ваш потолок трафика 10к в сутки — то никаким образом вы не упрётесь в эти ограничения — на апач будет лишь 10-20 одновременных подключений.
MaxRequestsPerChild — этот параметр задает максимальное количество запросов, обработанных каждым процессом, прежде чем оный будет перезапущен (уничтожен). Это означает, что ваше приложение с меньшей вероятностью может зависнуть или сожрать память. Процессы всегда «свежие», в которых наверняка нет каких-либо зависших запросов.

Настройка и оптимизация mysql или mariadb под нагрузку и производительность

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

Конфигурация mysql обычно где-то в /etc/my.cnf  (centos) или  /etc/mysql/my.cnf  (deb).

Основные настройки — это кэш и его объем, память под временные таблицы, буферы под выполнение определенных типов операций.


query_cache_size=256M
query_cache_limit=8M
join_buffer_size = 8M
tmp_table_size =256M
max_heap_table_size =64M
thread_cache_size=16
table_open_cache= 4000
max_connections=50
max_allowed_packet=300M

 

Все эти настройки описаны во множестве других мануалов, однако кратко пробежимся.

query_cache_size и  query_cache_limit — это первое что нужно включить.  Это объем кэша запросов. От его объема зависит эффективность работы, примерно так же как и с opcache — малый объем памяти не позволяет кэшировать все запросы, которые можно.

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

tmp_table_size и max_heap_table_size  — это тоже парные параметры, которые стоит использовать вместе.   Объем временных таблиц.

Дальше идут тоже размеры кэшей, но я точно не знаю как они влияют. Честно сказать, это особо и не нужно знать. Сейчас расскажу почему.

max_connections  — это важный параметр, который влияет на максимальный объем памяти, выделяемый mysql. Количество подключений, опять же одновременных. Подключения к базе данных это тоже такие операции, которых может быть немного даже при очень большом трафике.  Поэтому без крайней необходимости увеличивать его не стоит. Обычно когда такая необходимость возникает — вы увидите соответствующие сообщения в логах ошибок mysql/mariadb.   Часто при оптимизации следует даже уменьшить, особенно при увеличении буферов, типа join_buffer_size.  Поскольку тут идет перемножение — эти буферы умножаются на количество подключений.

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

Самый главный вопрос — какие значения в my.cnf указывать?

Очевидно что довольно сложно подбирать их эмпирическим путём.  Тут и возвращаемся к вопросу почему не так уж важно знать все эти параметры для настройки.  Ибо есть замечательная утилита mysqltuner, которая упрощает настройку mysql.  Она сверяет в настройки mysql с мощностью сервера и со статистикой их использования, на основе этого выдаёт рекомендации по увеличению тех или иных параметров.

Утилита устанавливается аналогично всему остальному софту из репозиториев — yum install mysqltuner (centos)  или apt-get install mysqltuner (deb, ubuntu). Она правда редко обновляется в репозиториях, и там версия менее функциональная, чем если поставить новую из исходников с гитхаба.  Но на 98% вам будет достаточно и этой.

После чего запускается просто вызовом без параметров

mysqltuner

Как посмотреть и прописать логин пароль mysql чтобы его каждый раз не вводить?

Иногда она выдаст сообщение о том, что не может подключиться к серверу. В этом случае с сервером mysql  у вас всё плохо и он действительно лежит. Если данные для авторизации не прописаны в конфиге в домашней папке пользователя, то нужно указать данные логин пароль.  Тут варианта два. Нужно либо указать при подключении логин пароль административного юзера, как правило root.  Этот путь хорош, если вам пароль известен, либо вы его можете посмотреть. К примеру, в ISPmanager 5 можно его увидеть в панели, вот так:

Либо, если у вас нету ispmanager, можно подсмотреть логин-пароль в файлике /root/.my.cnf  (обратите внимание на точку, это скрытый файл):

cat /root/.my.cnf

Выдаст нечто подобное:

Правда тут есть одно «но». Если у вас этот файлик есть, то mysqltuner просто отработает и всё.

Но если его нет, то и вот, заодно тут виден формат этого файлика —  пользуйтесь лайфхаком. Просто создайте его, и тогда вам не нужно будет вводить пароль при работе с mysql из командной строки.  Зачем вам это может вам понадобиться — это уже другой вопрос, но это очень мощное средство, которое позволяет заливать любых размеров базы, например, не упираясь в ограничения веб-аплоада, типа ограниченного объема файла, таймаутов вебсервера или глюков phpmyadmin.

Как пользоваться mysqltuner, что означает его вывод?

А мы продолжаем тюнить mysql.

Утилита выдаст что-то вроде такого:

 

Вывод делится на два раздела. Это статистика работы и рекомендации. Причем с указанием конкретных параметров и пороговых значений. Расписывать всю интерпретацию вывода это очень муторно,  и еще сложней объяснить как этим всем пользоваться.  Но суть такова, что в первой части вывода есть пункты, напротив которых не стоит статус «ОК».  Это не всегда проблема, некоторые из пунктов часто даже не решить, например «[!!] Temporary tables created on disk» — он обычно будет вылазить снова и снова, сколько бы вы не увеличивали tmp_table_size.  Тем не менее, если на вашем сервере настройки по-умолчанию, там будут другие параметры, и рекомендации, которые дадут существенную прибавку к производительности.  В частности, включение кэша запросов (помните да, что кэширование — это самая эффективная оптимизация? здесь тоже!).  Также и буферы, пулы. В общем, в самом низу вам выведется список параметров и пороговых значений.   Сделайте как там указано.  После чего понадобится рестарт mysql:

systemctl restart mariadb #(centos 7)

/etc/init.d/mysqld restart #старые системы и дебиан

service mysqld restart #новые deb — ubuntu

Но может и не сработать, ибо могут быть и другие варианты перезапуска, тут зависит от вашей OS и варианта СУБД — mysql или mariadb.

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

Часто будут просить еще увеличить что-то, а могут и появиться новые параметры.  Дальше повторяем процедуру с их изменением, рестартом mysql и повторным запуском тюнера после  «прогрева» базы.  Это может повторяться и 5, и 10, и даже 20 раз, особенно при отсутствии опыта и… каком нибудь перфекционизме 😀   Не стоит зацикливаться на буфере под временные таблицы, например. Обычно можно ставить его сразу побольше  1-2 гб — и больше не обращать внимания.  Но вот, innod_buffer_pool и query_cache_size — это вещи довольно важные, и их за несколько итераций следует привести к статусу «ОК».  В идеале это может выглядеть примерно так:

Проблемы при оптимизации mysql

Иногда ( а при отсутствии опыта чаще всего 🙂 ), вы можете столкнуться с проблемами при попытке оптимизировать mysql.  Например, mysql может отказаться перезапускаться, и показать что-то вроде fail.

В этом случае нужно срочно что-то делать, ибо ваши сайты отдают ошибку что не могут подключиться к БД 🙂

Бэкапьте конфиги перед любой настройкой!

Поэтому, всегда(!) делайте бэкапы конфигов ПЕРЕД ЛЮБЫМ В НИХ ВМЕШАТЕЛЬСТВОМ!   Это касается не только mysql, а вообще любых манипуляций описанных в данной статье. Лучше всего сделать бэкап всех конфигов, а они лежат в папке /etc/ , как вы могли заметить, если были внимательны.    Бэкап можно сделать например так:

rsync -avh  /etc/  /root/etc_backup_before_tuning/

Это означает сделать синхронизацию папки etc — в другую папку — /root/etc_backup_before_tuning/.  Поэтому, в случае какого-либо фэйла вы всегда можете взять исходный конфиг, вернуть на место, рестартануть сервис, и, скорей всего, он поднимется.

К примеру так:

cp /root/etc_backup_before_tuning/mysql/my.cnf   /etc/mysql/my.cnf

Именно в таком виде, только проблемный конфиг,  ни в коем случае НЕ  обратным откатом всех файлов!

Другой вариант:

cp /etc/mysql/my.cnf  /etc/mysql/my.cnf_orig

И откат:

cp /etc/mysql/my.cnf_orig /etc/mysql/my.cnf

Почему надо делать именно так, а не просто разбираться с ошибкой? Чтобы как можно быстрей вернуть сайты в работу, очевидно.   Вот после отката, можно уже спокойно разбираться с проблемой и выяснять что это было.

Как решать проблемы?

Всего одно слово.  Л-О-Г-И. Нужно смотреть логи.  Это относится к любому софту и к любым проблемам.  Там есть всё. Даже в тех редких случаях, когда там ничего нет, скорей всего просто не там смотрите 🙂  Логи нужно читать внимательно. Ошибки там обычно видно. Любая ошибка в 98% случаев гуглится и решается.  Другой вопрос насколько это может быть легко и быстро.  Я вот показывал скрины о фейле при рестарте mysql. Это реальная ситуация, я пишу эту статью, и для того чтобы всё это показать вам на практике — я делаю оптимизацию mysql на сервере, где работает вот этот сайт.  Итак, допустим, у меня не запустился mysql. Я иду читать лог. В ubuntu у меня  лог mysql где-то в /var/log/mysql/error.log. Он может быть и чуть в другом месте, но чаще всего именно в /var/log/

Открываю лог, и вижу, что mysql не может запуститься, потому что не хватает памяти под пул innodb. Я задал его в 360 мегабайт, ибо в рекомендациях мне показывало что данные сейчас имеют объем в 340. По-хорошему, нужно бы делать мегабайт 512, но у меня на этом vps всего 1gb памяти, поэтому я сделал 360, с минимальным запасом.   И то, я получил ошибку при рестарте, что все равно не хватает.  Я иду и уменьшаю до 256, тогда все запускается.  Но 256 это не оптимальное значение. Я знаю, что у меня большая часть памяти занята обработкой php, и он просто берет памяти обычно больше чем надо. Если я его рестартану, то часть памяти он высвободит, и скорей всего mysql запустится сразу после этого нормально даже с пулом в 360 мегабайт. Так и происходит 🙂 А хватит ли потом памяти для PHP, резонный вопрос?)  Я думаю хватит, ядро линукс очень хитрая и мощная штука, оно разрулит.

Кроме этого, я запустил mysqltuner еще раз, и увидел такую картину, на которой я сразу же нарисую решение:

Нужно обращать внимание на сообщение:

*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***

Особенно если памяти на сервере мало. Мало — это 1-2 гб. Если у вас там 8 и более, то иногда бывает небходимо задрать настройки mysql  такб что оно будет выдавать этот алерт, но при большом количестве памяти на него можно забивать. Чем больше памяти — тем меньше вероятности что её не хватит, даже если вы там выделили для буферов mysql в 2-3 раза больше чем её есть в системе.  Но в моём случае это обязательно нужно решить, если я не хочу  чтобы у меня начал падать mysql. Тут он почти со 100% вероятностью будет падать, если этого не сделать.  Самое простое  решение  уменьшить максимально разрешенный объем — уменьшить количество возможных одновременных подключений — max_connections. По-умолчанию оно может быть слишком велико, и пропорционально этому растет разрешенный объем памяти. 151 — это обычно и есть значение по умолчанию. А тюнер показывает мне, что используется всего 2.  Я уменьшаю до 50, думаю это с большим запасом, но при этом практически в 2-3 раза сократится максимальный объем выделенной памяти.   Так и вышло.

После этого я сделал еще 2-3 итерации с изменением параметров и запуском mysqltuner. И только тогда у меня показало то, что выше там есть как пример близкой к идеалу настройки.   Но то было как раз  при снятии статистики на «холодную», пока буферы и кэши еще не заполнились.  Через полчаса работы mysql без рестартов это выглядит так:

Фуххх…

Это почти всё было  о бэкенде, о том, что влияет на время ответа сервера.  Эти все вещи подходят для абсолютно любых сайтов, хоть статейных-информационных, хоть для сервисов, хоть для интернет-магазинов.   Далее речь пойдёт только о том, что можно использовать только для простых сайтов — статейников, информационных и дорвеев, конечно.  Причем, на любых CMS и доргенах 🙂

Кэширование Nginx — 100% решение проблем с любой нагрузкой и временем отклика

Но это не точно, не 100%.  Обычно… на 1000% и более.   Можно вообще всё вышеописанное пустить побоку и ничего не делать — включить одно лишь только кэширование в nginx, причем можно только для самых нагруженных сайтов. И это мало того что ускорит время отклика чуть ли не в 10 и более раз, но еще и снимет 80% нагрузки с сервера, если таковая имеется.

Всё довольно просто:

Этот «шедевр изобразительного искусства» я рисовал для другой статьи об ускорении сайтов.   Механика такова, что nginx очень быстро обрабатывает входящие запросы. Просто неебически неимоверно быстро!  Он способен отдать любую страницу из своего кэша за 0,1-0,2 секунды (100-200 ms) .  А если еще и железо быстрое — то он это может и за 0,06 сек. делать.  Как-то так:

Как то поспорили мы со Спартанцем, широко известным в узких кругах человеком, который разрабатывает всякий разный софт для нужд дорвейщиков.  Речь была о его плагине для wordpress  c лаконичным названием d.  Плагин интересный, позволяет неплохо разогнать wordpress, отключить кучу функционала, который может быть «лишним». Но он не решает одной очевидной проблемы — он не может работать без бэкенда.  Ему в любом случае необходим PHP, а значит apache, а значит всё так же подвержен тормозам при сверхнагрузках.

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

 

632 ms   — это нормальное время отклика для дефолтного wordpress.   Иногда можно разогнать до 300, но в среднем 0,5-1 сек.

Кэширование nginx ускорило его вот так:

 

Так на реальных сайтах бывает очень редко,  ибо тут может быть ограничено еще и медленным железом, дисками например (как проверить скорость дисков на сервере?)

Итак, кэширование nginx для wordpress реализуется примерно таким конфигом:


set $no_cache 0; if ($request_method = POST) { set $no_cache 1; } if ($query_string != "") { set $no_cache 1; } if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap(_index)?.xml") { set $no_cache 1; } if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $no_cache 1; } fastcgi_cache one; fastcgi_cache_min_uses 1; fastcgi_cache_valid 200 301 302 304 1h; fastcgi_cache_key "$request_method|$host|$request_uri"; fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache; fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie";

Самый важный параметр, который надо понимать в этом конфиге — это fastcgi_cache_valid. Он задает срок жизни кэша. Тут указан 1 час. Это означает, что все изменения на сайте будут появляться не позднее, чем через час после того как они сделаны. От срока жизни зависит эффективность работы кэширования. Очевидно — что чем меньше срок жизни, тем чаще будут запросы на бэкенд поступать, тем больше нагрузка и чаще будут отдаваться страницы не из кэша, а значит время отклика в среднем дольше. Но для очень часто обновляемых сайтов по-другому никак — например новостники, там бывает нужно обновлять контент каждые 10 минут. Соответственно это значение и нужно менять на 10m. Если же у вас сайт чуть ли не статический, например дорвей — то можно ставить срок жизни хоть месяц — работать со временем будет только лучше. С другой стороны, чем больше посещаемость ресурса — тем эффективней кэширование даже при малом сроке жизни. Т.е. представьте себе на очень посещаемом сайте 100 запросов в минуту с откликом по 1 секунде. Это очень пригружает сервер. Если же вы кэшируете хотя бы на 10 минут — то в течение этих 10 минут 1000 гипотетических запросов практически не создадут никакой нагрузки на apache и mysql, кроме первого запроса, т.н. «холодного старта» — пока страница еще не в кэше.

Здесь кэширование для связки nginx+php-fpm. Для apache соответственно fastcgi_ нужно изменить на proxy_
Это нужно включить в конфигурацию сайта. Можно и просто вписать, а можно добавить в отдельный файл, и включить в нужный сайт с помощью include, как я обычно делаю сам и рекомендую делать. Это нужно включать до каких либо location в конфиге.  Примерно так:

Кроме этого, нужно описать сам кэш в /etc/nginx/nginx.conf такой директивой:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=one:10m max_size=1024m inactive=1h;

Это нужно добавить в блок http. И снова надо помнить, что для apache директива должна быть proxy_cache_path. Это все что касается настройки.
Как проверить что кэширование работает? Очевидно по времени отклика. Если все работает — сайт будет летать. Но есть и другие способы.
Можно добавить директиву:

add_header X-Cache $upstream_cache_status;

Как обычно, после любых изменений конфигов нужно делать /etc/init.d/nginx restart

У вас в заголовках ответа после этого должен появиться статус кэширования, который может принимать три основных значения. MISS, HIT, BYPASS:

Статус HIT — означает что страница выдана из кэша. Время отклика будет у нее максимально быстрым. Противоположный статус — MISS, означает, что это «холодный старт» и страницы еще нету в кэше. После обновления этой страницы он должен смениться на HIT. Если не меняется — значит что-то либо не так делаете, либо вам этот конфиг не подходит. Такое тоже бывает, что нужна отладка, менять какие-то директивы, ибо какие-то другие настройки вебсервера могут мешать работе кэшера.

Статус BYPASS — это значит страница не кэшируется в принципе. Потому что её кэшировать нельзя, и для неё задано соответствующее исключение. Например админка, комментатор, post-запросы, поисковые запросы по сайту. Это всё описано в конфигурации, в подробности вдаваться не буду. Всё очень подробно документировано на официальном сайте.

И ещё один способ — можно посмотреть файлы в папке кэша.

Эта команда означает «найти только файлы в папке /var/cache/nginx/ и подсчитать их количество». Если количество не 0 — значит как минимум что-то уже работает 🙂

Этот способ ускорения и защиты от атак используется у известного всем сервиса cloudflare. Есть так же менее популярные решения типа айри.рф —  однако странно, что у них в зависимости от тарифа меняется некий коэффициент ускорения 🙂  Впрочем, мне доподлинно неизвестно какие технологии используют они, но подозреваю,  что всё то же самое, что я тут и описал, плюс CDN.  Но в CDN обычно нет необходимости, если всё это настроено.  Они предлагают оптимизировать даже интернет-магазины, а я утверждаю что кэширование Nginx плохо подходит для интернет-магазинов.  Но  и остальных возможностей бывает достаточно для оптимизации и сокращения времени ответа сайта.

Очистка кэша Nginx

Иногда бывает и такая необходимость. Например при смене дизайна, и необходимости сразу же увидеть изменения. Тут можно использовать тот же самый метод с удалением только файлов, чтобы nginx’y не пришлось заново создавать структуру папок в кэше.

find /var/cache/nginx/ -type f -delete

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

find /var/cache/nginx/ -type f |xargs grep site.com|xargs rm -f

Вместо site.com нужно указать свой домен, конечно.

Вот теперь, пожалуй, всё… что мне известно на данный момент об оптимизации серверов в максимально сжатой форме 😀

Разумеется, всё я это писал, прежде всего,  не по доброте душевной.  А в расчёте  на то, что кому-то понадобится  просто заказать оптимизацию сервера под нагрузку или сократить время ответа сервера 🙂   Но гайд полностью рабочий, если есть время и желание, разумеется любой может по нему настроить свой сервер.  Рождал я его чуть ли не неделю. Ну как, неделю. Непрерывного времени я думаю потратил часов 8-10.  Пост претерпел 39 редакций.

Стоимость и сроки оптимизации сервера

  1. Настройка  сайта  в режиме  php-fpm  — 1000 руб.   (для известных CMS. Для самописов  или каких-то малоизвестных CMS может быть дороже — от 2000 руб, ибо требует более сложной настройки и отладки)
  2. Настройка кэширования Nginx —  1000 руб.  (Аналогично. Для сервисов и интернет магазинов хотя и возможно, но крайне не рекомендуется, оно может работать некорректно)
  3. Установка и настройка акселератора PHP — opcache, xcache  — 500 руб.
  4. Оптимизация  настроек  mysql  — 1000 руб.
  5. Оптимизация настроек  apache,  установка nginx — под нагрузку, или наоборот под меньшее потребление ресурсов — 500 руб за каждый, соответственно.

На этом собственно исчерпываются потенциальные возможности по тюнингу под сайты. На сервере обычно больше нечего настраивать.  Однако, не всегда есть необходимость настраивать это всё.  Если вы не знаете что именно нужно настроить — я обычно предлагаю предварительный аудит сервера. В рамках которого я могу исследовать настройки, протестировать время отклика сайтов, выявить узкие места и определить возможности для оптимизации. После чего всю инфу выдаю в виде отчёта — что, где, и почему тормозит, и как это можно улучшить и ускорить.   Такой аудит стоит 1000 руб, в том случае, если больше никаких работ не требуется, или вы будете заказывать их не у меня.  В случае, если вам нужен только аудит — он будет стоить 2000 руб.

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

Комплексная оптимизация сервера стоит  3000 рублей.   В неё входит настройка — nginx, apache, mysql и акселератора PHP.

Сюда не включено кэширование Nginx, ибо оно идёт отдельной опцией, и стоимость его неизменна. При необходимости оно просто добавляется к стоимости комплекса работ.

Также и перевод на php-fpm обсуждается отдельно. Может быть включено в стоимость комплексной оптимизации только если у вас сайт на wordpress.

На любые работы я даю гарантию. Это означает, что в течение некоторого времени любые возникающие проблемы я решаю по возможности незамедлительно, а также консультирую по любым вопросам  в настройке сервера.   Если сделанная по результатам моего аудита оптимизация не дает никакого эффекта —  я не требую оплату.  ( Надо понимать, что сюда не отностится оптимизация, заказанная сразу — просто потому что вы решили что-то оптимизировать.  Разумеется я всегда предупреждаю что даст эффект, а что не даст. Но если вы всё равно хотите просто сделать оптимизацию — тут уже только ваши желания, и их исполнение должно быть оплачено в полной мере )

Кроме этого, также напомню, что я здесь не ускоряю сайт на 100 баллов по Google Pagespeed. Я ускоряю ответ сервера. А как оно повлияет (или не повлияет) на оценку гугла — это уже другой вопрос.

Оплату я принимаю исключительно после выполнения работ.  Разумеется, цены даны на текущий момент, и за мной остаётся право в любое время  их изменить.

Срок выполнения работ — примерно  2-3 часа, с момента, как я приступил к задаче. То есть всё будет готово обычно в тот же день. Но  последнее время всё реже бывает что я могу приступить сразу же, ибо бывает очередь из заказов.  Тогда я говорю день, в который я смогу заняться вашими задачами.

Ну вот, с коммерческой частью тоже вроде всё.

Вопросы и консультации  — в комментах. Или по контактам.  Желаю вам быстрых сайтов  и не «греющихся» серверов!

 

 

Отправить ответ

Notify of
avatar
moneyman
Гость

Супер-мануал, респект! Уже настроил себе opcache, спасибо 🙂

moneyman
Гость

У меня -40% к нагрузке на память стало (+ процу легче стало) и страницы WP открываются моментально практически — красота! 🙂 Правда памяти пришлось выделить 384 Мб (75% используется).

Еще один момент неуказанный в статье (в принципе мелочь, но я не сразу понял почему все установив у меня не работает opcache): если все вроде проверили и установили, то нужно еще перезапустить Apache, в CentOS 7 так: «systemctl restart httpd»

seoonly.ru
Гость

В закладки! Спасибо!

YoS
Гость

Спасибо дружище! Настроил наконец-то у себя Nginx + PHP-FPM. Годнота материала зашкаливает, однозначно в закладки!

Gandalf White
Гость

Годный мануал в закладки 🙂

Евгений
Гость

Включил opcache на php 7.1 как apache В настройки сайта в админке после этого не зайти, грузит и потом 504 ошибка. На php 5.6 все нормально.

wpDiscuz