Как снизить нагрузку на сервер на дешевом хостинге

Я начала свою борьбу с нагрузкой на сервер с 500 посетителей в сутки в далеком 2015 году и продолжаю её до сих пор. Я сижу на виртуальном хостинге за 120-190 руб. Все нижеследующее будет актуально и для владельцев выделенных серверов, но они смогут решать проблему и другими способами, не рассмотренными в этой статье, типа переустановить или перенастроить модули на сервере.

Большинство тарифов от самого распространенного виртуального хостинга Beget или  Sweb позволяют использовать 60-70 минут процессорного времени в сутки, но есть и не менее бюджетные хостинги которые позволяют использовать 120 минут. Естественно, я читала длинные чек-листы с хабра, пыталась применить на своем сайте, но не все мероприятия оказались одинаково эффективными.

Лучший метод диагностики проблем

Для начала нужно поставить диагноз сайту. Для этого стоит посмотреть в логи сервера на предмет подозрительных обращений и ошибок. Если нагрузка обрушилась на сайт резко, без всяких видимых причин, т.е. не обновлялись плагины, не менялась тема накануне, посещаемость не выросла, быстрее всего на сайт ведется атака или может быть залили вирус и нужно принимать меры против этих несчастий. Искать и удалять вирус или отбиваться от атаки. Например, подключить Cloudflare и включить режим «Under Attack Mode», как один из эффективных и бесплатных вариантов, но не единственный.

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

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

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

Плагин кеширования

Total Cache

Подходящий под хостинг плагин кеширования создаст наибольший выигрыш среди всех предпринятых мероприятий. Не все плагины кеширования одинаково эффективны. Для начала я поставила продвинутый Total Cache и была разочарована. Во-первых, у него очень сложная настройка, во-вторых я не заметила скачка нагрузки вниз. Многие функции не работали на моем хостинге, многие вместо того, чтобы снижать нагрузку наоборот её генерировали. Абсолютно точно это относилось к функции минификации html, css и js, установлено опытным путем.

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

Fastest Cache

Следующим шагом я заменила Total Cache на Fastest Cache. И я сразу ощутила эффект, на следующий же день нагрузка отскочила вниз. Fastest Cache сохраняет все страницы в виде html, я поставила срок перегенерации кеша раз в неделю. Настройка плагина очень простая, буквально несколько галочек поставить нужно и всё. Минификацию я не включила даже с установкой Fastest Cache. CSS и JS я сжала вручную онлайн. Я заплатила за платную версию, чтобы перенести загрузку файлов скриптов в footer, хотя на самом деле это типичный развод на деньги, брать 49$ за такую маленькую функцию. Я даже сама знаю в каком месте кода надо прописать несколько букв, чтобы достичь означенного результата.

LiteSpeed Cache

В 2020 году я перешла на использование LiteSpeed Cache. Этот плагин снизил нагрузку на сервер в 2 раза прямо сразу, но для того чтобы его использовать мне пришлось перенести сайт на новый хостинг. Чтобы плагин заработал необходим вебсервер OpenLiteSpeed, он есть не на всех хостингах. Я выбрала хостинг Fozzy, скидка 10% при использовании промокода TRIP-TOGETHER. Даже самый дешевый тариф там позволяет создавать нагрузку в 120 минут, так что рекомендую.

Ниже графики нагрузки. 10 апреля 2020 я переключила сайт на новый хостинг. По вертикальной оси отложены минуты на обеих графиках. Посещаемость практически одинаковая. Причем я и по окончании сотрудничества с Sweb много работала с сайтом, т.к. перешла на новую тему и возилась с настройками и по началу я много работала с сайтом на fozzy, полностью сбрасывала кеш по 3-4 раза в день. Моя возня в админской части и по ftp вообще никак не сказывается на Fozzy, а на Sweb это было ощутимо заметно, пики нагрузки были созданы при работе в админке.

Плагин кеширования нужно подбирать. Total Cache предназначен больше для выделенных серверов, для виртуального хостинга это плохое решение.

Снос лишних плагинов

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

Когда ситуация с нагрузкой стала угрожающей, пришлось посмотреть, а что же загружают плагины. Я использовала GTMetrix для этого. И я пришла в ужас от бессмысленности и беспощадности многих моих плагинов. Контактная форма грузила свои стили и скрипты на всех страницах сайта, хотя была установлена всего на одной странице. Usernoise загружал Font Awesome весом 500 Кб, чтобы вывести на лицо сайта одну маленькую звездочку. 500 Кб загружались абсолютно на всех страницах сайта.

Вместо контактной формы на странице контакты я просто указала свой e-mail, с Usernoise просто рассталась, как и с плагинами аналитики. Пусть сервера Яндекса и гугла работают, посмотрю аналитику там.

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

Правильная настройка оставшихся плагинов

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

1. iThemes Security пытался сделать бэкап базы данных. Естественно, ему не хватало для этого оперативной памяти, бекап не получался, но он упорно пытался. Этот  процесс приводил к избыточной нагрузке. В настройках плагина можно отменить эту функцию, на дешевом хостинге автоматический бэкап объемного сайта быстрее всего работать не будет.
2. NextScripts: Social Networks Auto-Poster пытался выполнять какое-то Cron-событие каждую минуту. Т.е. в сутки плагин создавал 1440 лишних обращений к серверу. Мне было лень разбираться, и я его отключила совсем. В логах сервера не видно что это был за Cron, пришлось поставить плагин WP Crontrol, чтобы выяснить это.

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

Пересмотр настроек плагинов может существенно снизить нагрузку на сервер.

Мой опыт использования CDN (Content Delivery Network)

Я дождалась очередного злостного письма от своего хостера Sweb. В связи с наступлением активного туристического сезона посещаемость моего сайта скачкообразно возросла и нагрузка на сервер, создаваемая процессами на моем сайте достигла критической величины 120 минут в сутки, напомню что согласно договору моему сайту положено было потреблять всего 60 минут процессорного времени в сутки.

Sweb предложил мне перейти на другой тариф стоимостью всего 800 руб. в месяц!!! Эта не гуманная сумма меня никак не устраивала, тогда я платила всего 120 руб. в месяц, повысить цену почти в 6 раз, это грабеж. В результате жаба меня задушила и я решила попробовать CDN от CloudFlare, в конце концов другого выхода у меня не было.

У  CloudFlare есть бесплатный тариф, именно на него я и подключилась. Больше всего беспокойства вызывало требование переписать на  CloudFlare мои DNS записи, но я сделала это, и в результате вы видите на графике нагрузка на сервер существенно снизилась до порога который Sweb склонен прощать. Момент подключения CDN  я отметила зеленой меткой на картинке.

Я конечно ожидала большего, мне мечталось увидеть цифру 30 минут в сутки, но этого не произошло. CDN это система серверов по всему миру на которые копируется ваш сайт и при запросе, например идущем из США, отвечает сервер расположенный в США, а не в Санкт-Петербурге, что должно сократить время загрузки сайта и попутно этот метод сокращает нагрузку на мой сервер.

Кроме системы доставки контента CloudFlare предлагает еще защиту от DOS-атак, аналитику и минимизацию html, css, и js.  Вот тут я включила минимизацию, раз CloudFlare берет это все на себя.

Бесплатный аккаунт  CloudFlare имеет ряд ограничений, что вполне естественно. За один запрос посетитель может загрузить с CloudFlare не более 100Мб и сервера обновляются в течении 24 часов. Т.е. если продать ссылку покупатель увидит ее не сразу, а в течении 24 часов.

Из недостатков CloudFlare я заметила следующие:

1. Функция Always Online совершенно не гарантирует показ вашего сайта, если ваш собственный сервер перестанет работать. Многие русские блогеры обещали такую фишку, но на самом деле это не так. На официальном сайте CloudFlare написано, что он не сохраняет абсолютно все страницы вашего сайта, он сохраняет первые 10 html- страниц сайта и лишь некоторые ссылки с них, сами понимаете, что это ничтожно мало для блога состоящего из 400 страниц. Поэтому, когда мой сервер падает, я вижу вместо своего сайта сообщение об ошибке от CloudFlare.
2. Мой сайт, подключенный к CloudFlare блокируется для интернет соединений, использующих TOR. Я это заметила сидючи в facebook, там я советовала свой сайт людям и некоторые мне отписывались, что страница не открывается. Что характерно, когда они заходили на мой сайт через мобильный интернет у них все открывалось, у меня тоже все открывалось, сайт в этот момент работал. Дело было именно в интернет соединении.
3. Невозможно одновременно использовать SSL сертификат от хостера и пользоваться CloudFlare на бесплатном тарифе. Бесплатный сертификат от CloudFlare не поддерживается на устаревших операционных системах и браузерах, типа операционной системы Windows Vista и т.д. Ставить свой собственный SSL сертификат можно только на тарифе 200$ в месяц.

Использование CDN даже на бесплатных тарифах способно существенно снизить нагрузку на сервер. При использовании платных тарифов можно вообще о ней забыть.

HeartBeat API

Нагрузка на сервер существенно возрастает в момент, когда я пишу статью, поскольку в этом случает работает мой сервер. Я отключила создание ревизий совсем и даже отключила возможности HeartBeat API, выполняющее автосохранение записи при написании статьи и прочие функции, необходимые, если редакторов на сайте несколько человек. После того, как мне пришлось переписать статью в 3000 слов по памяти, после отключения электричества я вернула эту опцию обратно. Очень она полезная.

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

Полное отключение HeartBeat API снижает нагрузку на сервер, но приводит к потере данных в случае форс мажора.

Переход на PHP 7

В октябре 2017 меня постигло очередное горе. После обновления wordpress и плагинов, нагрузка на сервер опять значительно возросла, это при том, что в сентябре посещаемость по сравнению с июлем меньше. В логах ошибок на сервере чисто. Вообще эта картина довольно типична, когда после обновления плагинов возрастает нагрузка на сервер.

Я перевела сайт на php7. Это было не просто. Сначала при переключении вместо своего сайта я видела белую страницу с надписью:«Ошибка соединения с базой данных». Хостер мне не смог помочь советами, пришлось разбираться самостоятельно. Оказалось я использовала устаревшее соединение с базой данных. Для его обновления нужно просто перегенерировать пароль соединения с базой данных и всё, но на поиски этого решения я потратила 2 дня.

После переключения нагрузка на сайт начала зашкаливать за разумные пределы, вопреки многочисленным предсказаниям о том, что она просто обязана упасть. Еще несколько дней раздумий и экспериментов и я решила и эту проблему. Оказалось в function.php моей темы я добавила (по советам от опытных вебмастеров из интернета) функцию, которая содержала в себе лишний цикл, давно уже. При работе на php5.3 перегрузки не возникало,  а после переключения на php7 просто начало зашкаливать. Когда я устранила эту проблему, я увидела свою нагрузку наконец в синей зоне.

Однозначно рекомендую переключить сайт на PHP7  и выше. Эта мера реально приводит к снижению нагрузки на сайт.

Очистка таблиц wp_options и wp_postmeta

Я прибегала к оптимизации базы данных все 10 лет существования этого сайта при помощи плагинов. Последние несколько лет для этой цели я использовала  все тот же плагин кеширования LiteSpeed Cache. Что делают все подобные плагины:

1. Удаляют спам-комментарии
2. Автоматические черновики
3. Удаленные записи
4. Временные данные — так называемый истекшие транзиенты

Вот ни один из них никогда не обращал моё внимание на таблицы wp_options и wp_postmeta (на самом деле у меня префикс таблиц не wp  и у вас наверное тоже, если вы заботитесь о безопасности своего сайта). А между тем в таблице wp_options было уже 1500 строк и суммарная автозагрузка составляла 137724715 байт, это на каждую страницу сайта при генерации загружалось столько в большинстве своем никому не нужного хлама. В таблице wp_options самый главный параметр — автозагрузка и у 1300 строк это параметр был равен yes.

Откуда же берутся все эти данные? Каждая тема и каждый плагин в зависимости от функционала при установке может генерить самостоятельные таблицы в базе данных, строки в wp_options и многочисленные строки в wp_postmeta. При удалении темы или плагина, как правило удаления этих данных автоматически не происходит. Т.е. чем старше сайт, тем эти таблицы больше и бессмысленнее.

Я обнаружила в базе данных многочисленные остатки тем, которые я только попробовала в далеком 2013-2014 годах, остатки плагинов, которые были удалены более 5 лет назад и плагинов, которые я только попробовала и сразу же снесла. Но и это еще не все, даже текущие плагины, которыми я пользуюсь много лет нагенерили уже безумное количество строк в wp_postmeta. Знаменитый Yoast Seo за годы пользования делал несколько капитальных обновлений и даже сносил некоторые устаревшие данные из таблиц, но опять не все.

Что я сделала с этим? Вручную через phpmyadmin просмотрела сначала все таблицы, снесла явно принадлежащие почившим плагинам и темам. Зашла в wp_options, вручную просмотрела таблицу и снесла данные устаревших плагинов и тем.

Большинство option_name из таблицы wp_options и meta_key из таблицы wp_postmeta содержит кусочек названия плагина или темы, по нему его можно опознать, но не всегда. Если такой кусочек названия опознан, можно сделать поиск по таблице wp_options и wp_postmeta и сразу снести все строки его содержащие. В результате суммарная автозагрузка уменьшилась до 300638 байт, т.е. в приблизительно в 460 раз.

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

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

Использование турбо-страниц от яндекса и amp от гугла

Я настроила себе обе эти опции еще осенью 2018 года. Но явного снижения нагрузки на сервер не заметила. Многие жалуются напротив на возрастание нагрузки из-за постоянного сканирования страниц amp гуглом и турбо-страниц яндексом. При использовании яндекс-турбо нужно кешировать rss-ленты. Яндекс засасывает эти ленты чуть ли не каждый час. Без кеширования турбо страницы однозначно приведут к перегрузке сервера.

Вообще я уже почти жалею, что я связалась с быстрыми страницами от гугла и яндекса. Реально я потеряла на этом изрядную сумму, потому что настройка размещения рекламы в несколько этапов продолжалась чуть ли не 4 месяца, пришлось купить еще один плагин за 30$ для размещения рекламы на amp, мучать свой мозг настройкой  adfox для показа рекламы на турбо-страницах. Если вы не приобщались к этим технологиям, то и не стоит начинать. Нет от них никаких привилегий. На посещаемость сайта внедрение amp и турбо-страниц не повлияло совсем никак.

Один раз после обновления плагина amp, всё пропало, на страницах amp появилась ошибка и вся посещаемость c amp благополучно перешла на обыкновенные страницы. Ничего не поменялось. Общая посещаемость осталась на том же уровне.

Использование технологий турбо-страниц от яндекса и amp от гугла никак не повлияло на нагрузку на сервер и посещаемость. Поэтому не советую.

Удаление лишнего из файла style.css и удаление лишних js-скриптов

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

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

Обычно из иконочного шрифта используется на сайте 5-10 иконок, а содержится их там около 500. Можно создать свой шрифт выбрав только нужные иконки при помощи сервиса fontello, объем загрузки снижается принципиально.

Использование Lazy Load, оптимизация изображений так же может немного снизить нагрузку на сервер, но не в моем случае. Мои изображения грузятся с Cloudflare.

Стоит признать, что лучше всего справиться с нагрузкой на сервер помог короновирус, обвалив посещаемость сайта. Нет посетителей нет нагрузки.

Мой хостер Sweb за 7 лет ни разу не отключил мой сайт за превышение нагрузки на сервер, хотя я почти всегда превышаю. Раньше Sweb присылал автоматические письма при превышении на 120 минут в сутки, после подарка в честь короновируса стал слать письма при превышении в 100 минут. Получение такого письма это просто повод задуматься и посмотреть в логи.

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

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

А у вас бывали ли когда нибудь проблемы с нагрузкой на сервер? Как справлялись? Какой хостинг используете? Может быть вы знаете еще какие-нибудь действенные способы по снижению нагрузки на сервер?