Інтернет Мастерская
Подборка полезных статей для веб-мастеров и заказчиков

версия для печати

Высокая нагрузка создаваемая WordPress-блогом на сервер и крайне несуразное решение этой проблемы

| источник: ktonanovenkogo.ru

 

Хочу поделиться с вами небольшим нюансом из жизни этого блога. Расскажу предысторию. Начиная с весны 2015 года у меня на повестке дня стоит одна и та же техническая проблема — периодически(несколько раз в день) на сервере, где расположен блог KtoNaNovenkogo.ru (и еще один сайт, который тоже работает на WordPress), нагрузка на память и процессор достигает 100%.

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

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

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

Эпизодически запредельная нагрузка WordPress на сервер

 

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

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

Однако, после традиционного «мы это делать не должны, но все же сделаем» ребята из техподдержки сказали, что судя по всему Ддоса нет (хотя какую-то фильтрацию агрессивных IP они все же настроили на всякий пожарный). Нагрузку же, по их мнению, генерит сам сайт.

Я же им отвечал, что в обычном режиме нагрузка крайне низкая, ибо на обоих WordPress блогах установлен плагин Hyper Cache с 10 дневным периодом обновления закешированных страниц. Собственно, в Parallels, который используется в Инфобоксе, есть панелька, где нагрузку на сервер по процессору и памяти можно отслеживать в реальном времени. Обычно там довольно идеалистическая картинка отображается:

Нагрузка на сервер

Но несколько раз за сутки эти значения вырастают до 100% (самый затык начинается, когда память забивается на все 100) и сайт даже со стороны посетителей начинает еле ворочаться. Техподдержка на протяжении всего периода моих обращений к ним что-то пыталась предложить, мониторили сервер в течении нескольких суток и ничего особо не замечали такого, на что можно было бы повлиять и «сделать всем нам хорошо».

Из того, что запомнилось перечислю:

  1. Меняли во все стороны значение максимального числа подключений (так и не понял чего это такое), но все без толку. По-моему, даже при увеличении этого числа сайт со стороны посетителей в момент высокой нагрузки тупил еще сильнее.
  2. Повышали тарифный план (на пару недель в тестовом режиме — без доплаты) с моего Linux VPS-2048 до 4 гигов оперативки и двойного увеличения процессорной производительности. Как ни парадоксально, но баги со 100% нагрузкой не только остались, но и приводили практически к полной недоступности сайта для посетителей (не смотря на кеширование), ибо страницы открывались по минуте. Поэтому экстренно все вернули взад.
  3. Переводили с обычного виртуального сервера (типа контейнер) в облако. Ничего не поменялось, разве что перегружаться сервер в этом режиме стал существенно дольше. Поэтому вернули опять же все взад.

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

Пришло в голову, что на эти периоды мой блог мог подвергаться брутфорсу (автоматическому перебору паролей для доступа в админку). Чтобы не возиться в htaccess и вручную не прятать файл авторизации, решил поставить плагин, который как раз препятствует брутфорсу — Login LockDown. Вроде он сейчас видит несколько попыток в час подбора пароля и пресекает их, но на «зависоны» это опять же никак не повлияло.

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

Собственно, в силу того, что перепробвано было уже все, что только могло прийти в голову мне или тем, кто писал на эту тему в интернете (в меру моих скромных умственных способностей, конечно же), верить в «чудо» я уже перестал и оно, как водится, пришло совершенно нежданным.

Как удалось решить проблему (надеюсь, что окончательно)

Все началось с того, что несколько дней назад что-то сподвигло меня посмотреть на исходный код одной из страниц своего блога. Дело это весьма полезное, ибо в шапке (между тегами Head) WordPress имеет дурную привычку пихать совершенно лишние метатеги и служебные гиперссылки link, которые могут ухудшать отношение поисковых систем к сайту.

За примерами долго ходить не надо — совсем недавно обнаружил там такую гадость, что волосы дыбом встали. Об ее обнаружении и удалении даже отдельный пост написал (хотя тема уже всплывала довольно давно, но я ее не воспринял тогда серьезно) — Проблема с All in One SEO Pack и ее решение.

В общем, за WordPress нужен глаз да глаз. Да, движок бесплатный, при этом профессиональный и попросту чумовой, но излишества всякие нехорошие нет-нет да и проскакивают. Вот. В этот раз взгляд тоже зацепился за «что-то новенькое». Это были три строчки кода (а точнее три служебных гиперссылки) опять же в шапке страницы формируемой WordPress:

Три новых служебных ссылки в шапке WordPress 4.4

Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).

В общем, сие пока решил отложить до прояснения ситуации и появления рецептов «купирования ненужных отростков». Да, опять же, если в теме, то расскажите, ибо сильно эти ссылки меня раздражают. Хотя бы для чего они нужны и не несут ли какого диструктива в продвижение блога. Но тут я пока отступил.

Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:

Отображение эмодзи смайликов в WordPress

Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово emoji в коде. Недавно писал про коды эмодзи смайликов, которые можно использовать для их вставки. Чуток погуглил и убедился, что таки да — этот код помогает отображать на старницах WordPress эти самые эмодзи смайлики.

Так как emoji смайлы у меня выводятся отсилы в двух-трех статьях, то решил это безобразие убрать, для чего и был произведен поиск рецепта в сети. Решение, как всегда в таких случаях, состояло в добавлении фильтров в файлик функшион.пхп из папки с используемой вами темой оформления WordPress. В общем, находим в нем место окончания какой-нибудь функции (точку с запятой) и туда добавляем несколько строк непонятного (мне), но вполне себе работающего кода:

remove_action( ’wp_head’, ’print_emoji_detection_script’, 7 );

remove_action( ’admin_print_scripts’, ’print_emoji_detection_script’ );

remove_action( ’wp_print_styles’, ’print_emoji_styles’ );

remove_action( ’admin_print_styles’, ’print_emoji_styles’ );

remove_filter( ’the_content_feed’, ’wp_staticize_emoji’ );

remove_filter( ’comment_text_rss’, ’wp_staticize_emoji’ );

remove_filter( ’wp_mail’, ’wp_staticize_emoji_for_email’ );

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

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

<script type="text/javascript">
   window._wpemojiSettings = {"baseUrl":"http://s.w.org/images/core/emoji/72x72/","ext":".png","source":{"concatemoji":"http://ktonanovenkogo.ru/wp-includes/js/wp-emoji-release.min.js?ver=4.4"}};
   !function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL().length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0),0!==d.getImageData(16,16,1,1).data[0])):!1}functione(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag"),unicode8:d("unicode8")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag&&c.supports.unicode8||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings);
  </script>
  <style type="text/css">
img.wp-smiley,
img.emoji {
 display: inline !important;
 border: none !important;
 box-shadow: none !important;
 height: 1em !important;
 width: 1em !important;
 margin: 0 .07em !important;
 vertical-align: -0.1em !important;
 background: none !important;
 padding: 0 !important;
}
</style>

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

Как пришло осознание

 

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

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

Во всяком случае по срокам и по тому, что проблема не проявляется после удаления кода поддержки эмодзи, можно было сделать определенные выводы. Я их сделал и написал этот пост. Если проблема вылезет опять, то чуть ниже появится P.S. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).

Решение получилось действительно несуразным, по крайней мере глядя с моей, крайне невысокой в умственном плане, колокольни. Где логика? Не знаю, но все равно приятно, что пусть и случайно, но мучивший меня довольно долго технический казус более-менее удачно разрешился. За сим разрешите откланяться. Спасибо за внимание и еще раз с Наступившими праздниками.

Поставить ссылку в соцсети

комментарии

Чтобы поместить сообщение или комментарий вам нужно войти под своим логином  »»