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

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

Я же им отвечал, что в обычном режиме нагрузка крайне низкая, ибо на обоих 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 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).

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

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

Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово 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}function e(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. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).

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