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



С таким запросом к нам обратился Михаил.  У него на виртуальном сервере десяток сайтов, суммарным трафиком около 2к хостов в сутки.  И VPS с минимальным  тарифом у хостера с 1 гб  оперативной памяти, одним ядром CPU и 20 Gb SSD.  Сайты на WordPress.   На сервере кроме этого также стоит панель управления хостингом ISP Manager Lite 5.

vpsadm.ru помогает!

vpsadm.ru помогает!

Клиент изначально обратился за настройкой сжатия, которое требуется при оптимизации сайта под Google Pagespeed Insights.   Он пытался включить сжатие самостоятельно в настройках сайтов через панель ISPM, но Гугл упорно не хотел «видеть»  что сжатие включено.

Кроме того, среди жалоб  оказались и другие проблемы:  VPS периодически зависал, в часы пик сайты открывались очень медленно, в логах были ошибки.

Что такое Google Pagespeed Insights?
Google Pagespeed Insights это хороший инструмент, который позволяет вебмастерам оценить производительность своего сайта. Гугл показывает состояние основных  настроек вебсервера, таких как сжатие файлов для уменьшения трафика и ускорения сайта, кэширование на стороне клиента — в браузере (а еще есть серверное кэширование Nginx), оптимизацию изображений, javascript, css.  Таким образом, через этот инструмент можно очень быстро сделать аудит сайта по которому специалисту сразу же становится понятно, где и что нужно изменить, для того, чтобы сайт стал работать лучше, по мнению Google.  К счастью, его мнение совпадает с мнением большинства пользователей.







Как включить сжатие и кэширование на сайте?

Как оказалось в итоге, сжатие было включено не до конца, поскольку панель управления от ISP просто  не позволяет настолько гибко настраивать вебсервер. При подключении к консоли сервера через SSH  и исследовании конфигурации Nginx, быстро выяснилось, что сжатие на самом деле-то и не включено, поскольку отстутствует важная для этого директива gzip_types.

Для того чтобы включить сжатие, достаточно добавить в файл конфигурации виртуалхоста следующие строки.

gzip on;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;

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

gzip_comp_level 5;

Вообще, nginx   поддерживает  9 уровней сжатия, как и gzip, через который оно делается.  5-6й уровень считается оптимальным по соотношению сжатие/производительность. Поскольку при дальнейшем увеличении уровня сжатие будет улучшено очень мало, в то время как это существенно увеличит нагрузку на процессор.  Поэтому рекомендуется вообще не указывать уровень сжатия, либо указать его не более 5-6.

Теперь поговорим о клиентском кэшировании.

Что такое кэширование с точки зрения Google Pagespeed?








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

Именно это Гугл требует включить на вебсервере. Для разных разных вебсерверов это делаетс по-разному для Nginx рецепт прост.

Нужно использовать expires.

Например так:

location ~* \.(js|css|png|jpg|jpeg|gif|ico|woff)$ {
expires max;
log_not_found off;
}

Этот вариант сообщает браузеру клиента кэшировать описанные типы файлов насовсем — max. Вместо max можно указать количество часов — 2h, дней (3d)  или месяцев (1m). Кроме того, в этой конфигурации даётся указание на записывать в лог вебсервера сообщения с 404 ошибкой для этих файлов. Например, если будет запрошен файл картинки или скрипта, которых уже нет на сервере.  В некоторых случаях, это также помогает снизить нагрузку на сервер. Особенно когда на сайте произошли существенные изменения и поисковые боты в попытках проиндексировать ищут старые файлы на сервере.   Отключив логгирование этих событий мы снижаем нагрузку.  Кстати, есть даже особый способ атак, который основан на этом — запрашивать у вебсервера множество страниц, которых заведомо не существует на сайте.

Как включить сжатие и кэширование для вебсервера Apache?

В некоторых случаях используется именно этот вебсервер. Хотя nginx сейчас что называется «в тренде», старичок Apache 2 еще используется многими хостерами и вебмастерами.   Как минимум в качестве бэкенда. Здесь  придётся сделать отвлечение на анатомию сервера.

Что ещё за бэкенд?
Дело в том, что серверное программное обеспечение и сами информационные системы, в том числе и сайты, обычно разделяют на backend и frontend.  Бэкенд — это  «задняя» часть — от английского back —  которая скрыта от пользователя и представляет собой основу сайта — база данных и исполняемые файлы CMS — чаще всего на php. Так вот, backend отвечает как раз за работу этих частей сайта. В то время как фронтенд — это перед, лишь то, что видит посетитель сайта или сервиса — его интерфейс. Это непосредственно то, что отображается в браузере — html-код страницы, стили, javascript  изображения, контент.  В упомянутом мной контексте nginx — это обработчик фронтенда, он прекрасно умеет отдавать статические элементы. Но для исполнения php-кода  сайта необходим обработчик, а nginx этого не умеет.  Так вот, apache — умеет отдавать и фронтенд и бэкенд — такой себе универсал.  Но делает это весьма посредственно.  Я об этом рассказал, поскольку дальше в кейсе это будет иметь значение.

Итак, для того чтобы сконфигурировать вебсервер apache под Google Pagespeed Insights  нужно также  включить сжатие и кэширование

Это можно сделать как для всего вебсервера, так и для каждого сайта в отдельности.

Также это можно делать в разных местах. Простейший путь — добавить в файл .htaccess такой код:

# сжатие text, html, javascript, css, xml:
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>

# Включаем кэш в браузерах посетителей
<ifModule mod_headers.c>
    # Все html и htm файлы будут храниться в кэше браузера один день
    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=43200"
    </FilesMatch>
    # Все css, javascript и текстовые файлы будут храниться в кэше браузера одну неделю
    <FilesMatch "\.(js|css|txt)$">
        Header set Cache-Control "max-age=604800"
    </FilesMatch>
    # Все флэш файлы и изображения будут храниться в кэше браузера один месяц
    <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
        Header set Cache-Control "max-age=2592000"
    </FilesMatch>
    # Отключаем кеширование php и других служебных файлов
    <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
        Header unset Cache-Control
    </FilesMatch>
</IfModule>
Эффект от этих настроек можно увидеть в нашей инфографике:

 

Итак, сжатие и кэширование включено, сайты заработали пошустрее, оценка google pagespeed insights местами «позеленела».  Но проблемы были не только в этом, поэтому будем разбираться дальше.

Исследуем системные логи

Там сразу же замечаем проблему — apache валится с ошибкой о нехватке памяти — out of memory.

Ошибка при зависаниях Apache

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

Клиент также жалуется, что показывается ошибка 502 — Bad Gateway.  Такое случается, когда Apache не успевает обрабатывать поступающие запросы.    Пробуем включить на сервере ещё один тип кэширования — APC.  Это особый модуль PHP, который выполняет «прекомпиляцию» кода  и сохраняет результат его выполнения в оперативной памяти.  Затем, повторные запросы к одним и тем же страницам не приводят к исполнению того же самого кода, если в нем не было изменений, а позволяют вебсерверу отдать уже готовый результат из кэша.

Итог — страницы стали открываться  шустрее, но иногда всё равно показывается 502 ошибка.  В частности в консоли администратора WordPress.   Оно и понятно, эта часть сайта наиболее сильно может нагружать вебсервер, поскольку при обращении к ней серверу приходится выполнять десятки, а то и сотни php-скриптов. Благо, что пользователи туда не ходят.

Но проблема имеется, остаётся моё любимое средство — убрать apache и заменить его на обработчик php-fpm.

Замена apache на php-fpm (fastcgi)

Это быстрый сервер, который умеет выполнять  только php-код, но не умеет отдавать статические файлы и html-код. Но нам это и не нужно — у нас есть отличный обработчик фронтенда в виде вебсервера Nginx. Более того, я считаю моветоном, ставить Nginx перед apache.  Ну это всё равно что засунуть в шасси и кузов болида  формулы-1 старый двигатель от «Жигули».    Машина может ехать быстро — но двигатель чихает  и не тянет.    Однако, хостеры и многие системные администраторы используют именно такую схему.  Почему? Потому что так проще, ведь php-fpm несколько сложнее в настройке.

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

А недостатки?  Apache не тянет нагрузку. Там где появляется нагрузка — она будет расти в геометрической прогрессии. Даже на очень мощных серверах сайты могут «тормозить».  По моей оценке — apache может выдерживать нагрузку лишь в сотни посещений. Если перед ним поставить nginx  для отдачи статики — тысячи.  Но там где нагрузка в десятки тысяч посещений — apache начинает захлёбываться.  Это могут подтвердить и многочисленные бенчмарки.

То же самое мы видим и здесь.

Результат оптимизации сервера

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

На что способен nginx+php-fpm?
Я помню готовил систему документооборота к нагрузочному тестированию.    Система как раз таки работала на apache, в результате было выявлено, что требования, предъявляемые заказчиком способна выдержать только эта связка — nginx+php-fpm. Причём, нам бы даже не помогли мощные сервера с десятками гигагерц и ядер CPU и сотнями Gb оперативной памяти.  Потребовалось спроектировать  архитектуру  системы из  20 серверов, чтобы выдерживать 20 тысяч одновременных подключений.  Apache не выдерживал даже 2 тысячи, и делал это в разы медленней fpm.   Php-fpm справлялся, но потребовалось масштабировать его на десять хостов. И перед ними стоял один-единственый балансировщик с nginx,  который легко принимал на себя всю нагрузку и при этом даже не напрягал оборудование.  А вот серверы для обработки php были нагружены на 50%.

Тогда тестирование проводили не кто-нибудь, а независимые эксперты из компании Hewlett Packard. Они специализируются на инструментах для нагрузочного тестирования — у них есть такой продукт Load Runner.  Вот им и тестировали.  Это был конкурс на выбор системы электронного документооборота, участвовали 5 систем.  Уж и не помню какие там были результаты у других систем, но мы требования заказчика выдержали.

Тем более что наш менеджер схитрил — нам было дано задание оптимизировать и тестировать  до тех пор, пока система не будет выдерживать 20 тысяч одновременных пользователей.  А оказалось, что у заказчика предъявлялось требование  в 10 тысяч. Стоит ли говорить,  что в итоге построенная нами распределенная система показала,  что нагружена она всего лишь на 30% под тестами HP. Имея такой запас прочности эта система легко победила в конкурсе и была выбрана заказчиком. 

Всё это хорошо, а что же получил клиент в рассматриваемом здесь кейсе?

Клиент получил «зелёные» оценки почти по всем десяти сайтам. Исключением стали только три сайта, на которых Гугл «забраковал» неоптимизированные изображения.

Как было до настройки VPS

Примерно вот так выглядели результаты тестов Pagespeed Insights когда мы получили VPS в работу:

Результат теста pagespeed

Оценка Google и скорость загрузки до оптимизации

А вот так выглядел график нагрузки VPS в панели ISP manager:

 

тормозят сайты на vps

Нагрузка на VPS от вебсервера Apache

Как видно по графику, нагрузка на CPU зашкаливает 70% процентов практически постоянно.  А это, как минимум, тревожный звонок.   Ну и, собственно, проблемы, в виде тормозящих сайтов и вылетающих ошибок, клиенту приходилось перезагружать сервер.  К слову, весь сервер-то и не нужно, достаточно рестартануть апач (httpd в службах centos).

Вот так мы его перенастраивали:

Смена apache на fpm, график нагрузки

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

Вот такую картину мы видим  в течение двух дней после:

нагрузка при работе сайтов на php-fpm

Работа оптимизированного VPS

Снижение нагрузки в два-три раза  очевидно, друзья.  А то и более.  Сервер утилизируется теперь процентов на 30, и выдержит  даже если на сайтах будет многократный рост трафика.  Хотите я вам скажу сколько он выдержит? А ведь это самый дешевый тариф у хостера, рублей за 200.    Впс,  настроенный таким образом,  выдержит до 20 тысяч (20k, карл!) суточного трафика.  Это при использовании wordpress с плагином wp-supercache, а все мы знаем насколько прожорлив WP.

Как растет нагрузка на сервер?

Как растет нагрузка на сервер?
Откуда инфа?  И   как он выдержит 20000, если  он показывает 30% загруженности при 2000 посещений.  Вот такая хитрая математика, друзья.  Дело в том, что нагрузка на оборудование и софт сервера не растёт линейно.  Она растёт по своеобразной  отрицательной экспоненте, что ли. Мы пока ещё исследуем этот вопрос, но есть очень много затей на эту тему, так что заглядывайте почаще, может мы и найдем такую формулу.

Так вот, значит,  рост нагрузки замедляется  при её увеличении.  Это связано с особенностями построения программ, сайтов, и даже железа.  До некоторого момента,  такой системе без разницы — обработать 1 запрос,  10 запросов или 1000  — нагрузка будет почти одинаковой, сервер и сайты на нем практически не замечают роста.    Затем, наступает какой-то  перегиб,  и рост нагрузки становится действительно линейным. Вот тут-то и нужна максимальная оптимизация. А когда информационная система отлажена — дальнейший рост нагрузки для неё замедляется, потому как происходит своеобразное наложение и совмещение функций —  один и тот же исполняемый код используется многократно,  работают всевозможные кэши, система, что называется «разогрета».

Ну дак, заявление  о 20к трафика на 1гб RAM  VPS   чем-то обосновано?  Да друзья, я таким же образом оптимизировал VPS c 512 Мб ОЗУ  и 1 CPU. На нём работал 1 сайт на wordpress, который выдерживал около 5000 визитов и 15000 хитов в сутки.  Да он и по сей день работает, хотя проект  и переживает не лучшие времена и  трафика там  на данный момент существенно меньше. Так вот, при 5к трафа при глубине просмотра 3 страницы на посетителя,  VPS показывал всего лишь 50% загруженность.

Да вот статистика того сайта:
 

Быстро ли работают сайты после оптимизации?

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

Сайты стали открываться вот так:

оценка работы сайта на оптимизированном VPS

Оценка Google Pagespeed того же сайта после оптимизации VPS

Это тот же самый сайт, который был показан ранее в статье.

А вот это уже другой сайт. Удивительно, но Гугл порой считает, что даже 0,27 секунды — это долгое время ответа сервера.  Этот сайт тоже на WordPress.

сайт на оптимизированном  VPS  показывает 92 балла

Оценка pagespeed после оптимизации сервера

Итого, скорость отклика улучшилась с 2-секунд, до 0,2 секунды, в некоторых случаях.    Меж тем, некоторые коллеги упорно не желают верить в то, что это работает, и даже возник спор в  топике на серче.   Собственно, тот спор и послужил почвой для этого кейса.  Но не думаете же вы, что я нарисовал всё это в фотошопе, друзья? :)

Куда обращаться в случае чего?

В спортлото пишите!

Шучу.

Можно заявку оставить на сайте vpsadm.ru,  можно писать по контактам,  указанным там же. Консультироваться можно  в комментариях, а можно постучаться опять же в скайп.  Можно и на любом форуме, где у нас есть топик, куда можно попасть из блока отзывов на сайте vpsadm.   Например, на mfc.guru люди так и получают бесплатные консультации.

 

Кстати, подписывайтесь на обновления, следующая статья будет об увеличении дискового пространства на VPS засчёт подключения внешних файловых систем, облачных или с других VPS.

Комментариев

  1. drmotor :

    Ответить

  2. Pacman :

    Ответить

  3. Василий :

    Ответить

    • drmotor :

  4. Василий :

    Ответить

    • drmotor :

  5. Михаил :

    Ответить

    • drmotor :

Сохраните для друзей или чтобы прочесть в другой раз:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *