16 тонн. Как я спасал гибнущий под нагрузкой сайт на WordPress, имея весьма поверхностные знания в области этой CMS

Статья будет короткой и сумбурной — я пишу ее с целью скоротать пару часов перед тем как начать откатывать сайт к предыдущему «нормальному» состоянию.

Эта история началась пять часов назад. Ко мне обратился владелец одного тематического новостного сайта. Тематика — спортивные соревнования. У сайта есть две проблемы. Во-первых, в моменты крупных и сильно ожидаемых состязаний количество посетителей на сайте увеличивается на порядок. Вторая проблема — он сделан на WordPress, причем довольно небрежно. Думаю, что изначально это был обычный WP-сайт. Но потом он многократно «дорабатывался»: куда ни попадя втыкались разные рекламные блоки, вводились новые «решения», ставились всякие плагины для «оптимизации» и расширения возможностей. Кроме того, каждый день, на протяжении нескольких лет, появлялось около десятка постов. Размер БД — несколько гигабайт, ‘upload’ идет на десятки гигабайт. Со временем сайт превратился во что-то похожее на это:

image

И вот, где-то в 0.00 по Москве сайт начинает падать под наплывом любителей спорта. Главная страница то отдает код 500, то загружается дольше минуты. Подозреваю, что периоды таких «набегов» посетителей — самое хлебное время для подобных ресурсов: клики, ставки и все такое. Владелец нервничает, что, в общем-то, понятно. И так получается, что из тех, кто не спит в эту субботнюю ночь и что-то понимает в веб-разработке у владельца есть только я.

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

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

Разумеется, первая мысль — пойти по пути наименьшего сопротивления. Т.е. просто перейти на старший, более «мощный» тариф. Сайт размещен на VDS. И тут выясняется, что этот способ не пройдет: переход на большие ресурсы — только по заявке в тех. поддержку хостера. Срок исполнения — от нескольких часов. Хостер объясняет это виртуализацией KVM. Ok, этот вариант не подходит. Одновременный звонок в поддержку и чтение сайта хостера занимают около пяти минут.

Следующий вариант, который проносится в моей голове: «WordPress славен своими плагинами. Я даже помню названия двух плагинов для кэширования: WP Super Cache и WP Fastest Cache». Как я узнаю позже, оба входят во всякие списки вроде «Топ-10 плагинов кэширования для WP» и т.п. Я подозреваю, что устанавливать плагины на постоянно падающем сайте — очень неприятное занятие. Поэтому сайт около пяти минут работает только для меня. Я быстро ставлю первый плагин, пробегаю глазами настройки — вроде все ok. Включаю сайт для всех посетителей. Результат… Ноль. Возможно, что-то улучшилось, но это как мертвому припарки — улучшение незаметно невооруженным глазом. Сайт упорно продолжает падать. Неудачный выбор плагина? Еще быстрее жму на кнопки и ставлю второй плагин. Результат… Да такой же. Сношу и этот плагин. На все эти манипуляции у меня уходит почти пятнадцать минут.

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

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

Руки начинают искать и скачивать чистый дистрибутив WP, а голова — думать. Перед глазами стоит образ дядюшки, который любил часто (и весьма ехидно) говорить мне во времена моей юности: «Знание немногих принципов часто заменяет знание многих фактов». И вот о чем я подумал:

  1. Все запросы на выдачу страниц сайта, скорее всего, проходят через некоторую единую «точку входа», роутер. Там определяется (или начинает определяться), что и в каком порядке будет дальше подключаться/считаться/выводиться.
  2. Дальше, собственно, все подключается, считается и, к сожалению, выводится. Именно тут, скорее всего, происходит пожирание ресурсов. На бесконечные запросы к БД и прочие ужасы.
  3. Ужасы заканчиваются, а результаты в некоторой «точке выхода» отдаются пользователю.

И если это все хотя бы примерно так, то можно применить систему кэширования, которую я называю «Топор». Кроме того, на этом сайте всем посетителям отдаются одинаковые по виду страницы. Т.е. конкретному URL соответствует страница, которая будет выглядеть одинаково для любого пользователя. Ну, кроме тех, что авторизовались в админ. панели WP, но они не в счет. Сейчас это только я.

Теперь нужно найти упомянутые выше точки «входа» и «выхода». «Вход» обнаруживается в файле /index.php. В котором честно написано: «This file doesn't do anything, but loads...». Чудненько. С «точкой выхода» сложнее, но я вспоминаю, что что-то слышал про событие «shutdown» в WP, которое выполняется после всего. Быстрым поиском по чистому дистрибутиву нахожу функцию «shutdown_action_hook» в /wp-includes/load.php. Еще быстрее, написав внутри нее «echo» проверяю в каком месте страницы она выведет «GoldenAxe!». В конце. Отлично! Искомые точки найдены, на все ушло около 10 минут. Теперь нужно как-то реализовать очень простую логику:

  1. При первом обращении к странице она генерируется как обычно. После того, как весь вывод сгенерируется, его нужно будет записать в отдельный файл. Произойти это должно в «точке выхода». Файл нужно будет записать в папку /_cache/. Имя файла будет выглядеть следующим образом: md5-хэш URL страницы (без параметров), которая запрашивается. Т.к. это единственный параметр от которого зависит вид выводимой страницы, то этого вполне достаточно.
  2. При втором обращении к странице в «точке входа» мы будем проверять есть ли в папке с файлами кэша нужный (с соответствующим запрашиваемому URL md5-именем). Если есть — сразу читаем из него и выводим результат.

Все. Вся система. Остается только придумать как собрать вывод. Как многие знают, шаблоны WP — это адская смесь HTML и PHP. Т.е. в них постоянно встречаются конструкции вроде:

<?php 
	if($Some==1) echo '<div class="novost">';
	else echo '<div class="statya">';
?>
	<div class="item"></div>
</div>

Я считаю, что это ужасно. Но так есть. Таким образом, у нас нет некоторой переменной $Content в которую бы собирался весь контент страницы перед выводом и уже затем выводился один раз с помощью того же «echo». У нас есть сотни этих «echo» в шаблонах. И их нужно как-то собрать. Когда-то давно, когда я читал мануал к PHP я встречал там функцию «ob_get_contents()». Я никогда ей не пользовался, но тут она пригодилась. Она возвращает содержимое буфера вывода и идет в компании с функциями «ob_start()» и «ob_end_clean()». Первая включает буферизацию, вторая — выключает и очищает буфер. Все это я мгновенно загуглил. Прошло еще пять минут. Вот какой код я в результате поместил в «точку входа» и «точку выхода»:

<?php

// «Точка входа»: 

$URL_WO_QS = strtok($_SERVER["REQUEST_URI"], '?');

$CacheFile = $_SERVER["DOCUMENT_ROOT"].'/_cache/'.md5($URL_WO_QS).'.cache';

if(file_exists($CacheFile) && intval($_REQUEST['test'])!=1){
	
	echo file_get_contents($CacheFile);
	exit();
	
}

ob_start();

// ....
// ....
// ....
	
// «Точка выхода»: 

$Result = ob_get_contents();

ob_end_clean();

$URL_WO_QS = strtok($_SERVER["REQUEST_URI"], '?');

$CacheFile = $_SERVER["DOCUMENT_ROOT"].'/_cache/'.md5($URL_WO_QS).'.cache';

file_put_contents($CacheFile, $Result);

echo $Result;	

?>

Ну а дальше оставалось только проверить результат. Я специально оставили себе возможность запросить сгенерированную стандартным способом страницу (передав в URL параметр «test» для $_REQUEST в «точке входа»). Получив выдачу страницы после кэширования «Топором» я сравнил ее со «стандартной» выдачей. Нашел небольшое отличие — в кэшированную версию не попал один js-скрипт. Тот, который отвечал за загрузку дополнительных постов в список при нажатии на кнопку «показать еще посты». Выяснять почему он не попадает в вывод было некогда, поэтому я просто добавил вызов скрипта в шаблон. И все заработало.

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

А плюс один, зато большой: сайт перестал отдавать код 500 или ждать ответа и выдачи страницы по полторы минуты. Теперь сам вывод (ответ страницы) занимает около 40 ms вместо 1.5 m и все пользователи без исключения могут нажимать на рекламу. Конечно, полная загрузка страницы занимает больше времени: многочисленные неоптимизированные изображения, скрипты рекламы и прочие шрифты делают свое дело. Но глазу это незаметно. Сайт работает быстро.

На все внедрение моего «Топора» ушло не более получаса. Сейчас я пойду снимать его и возвращать сайт в исходное состояние. Спортивное соревнование окончено, фанаты, а с ними и я, идем спать.

Не судите мое решение слишком строго. Помните, что я принимал его в условиях жестких временных ограничений и без серьезных знаний WordPress. Возможно, существовало более изящное и правильное решение. Если вы его знаете — напишите в комментариях. Я же могу сказать, что чувствовал себя ветеринаром, которому пришлось оперировать человека. Ну или наоборот. Хорошей вам погоды, друзья!

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

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

Несомненно, правильное решение проблемы этого сайта в общем выглядит так: «ищем причины низкой производительности с помощью разных инструментов и методик. Препарируем локальную копию сайта. За чашечкой чая обдумываем решения, проверяем их. Обновляем рабочую копию. Анализируем ее работу и эффективность обновлений. При необходимости вносим правки. Все!».

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

Некоторые из комментаторов пеняют мне на криворукость. Мол, я не смог расставить в нужных местах галочки в настройках плагина WordPress. С вероятностью 90% причина все-таки не в этом. Как я узнал позже, сравнив чистый дистрибутив той же версии WP с тем, что есть на сайте, правились даже те файлы WP, которые, как я понимаю, являются «системными». И правились весьма обширно. Что, по идее, совершенно недопустимо. Таким образом, вероятность штатной работы системы, которую мы называем «WordPress» резко снижается. В том числе и вероятность того, что она штатно будет взаимодействовать с плагинами кэширования. Фактически, в данном случае, мы имеем «черный ящик», некоторый кастомный проект на базе WP.

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

В общем, статья — не столько о конкретном техническом решении, сколько о самой ситуации. Так я и прошу вас к ней относиться. Как к истории о поиске быстрого, безопасного и удовлетворяющего задаче решения в экстремальных условиях. И (мне бы этого хотелось) как к иллюстрации на тему «Знание немногих принципов часто заменяет знание многих фактов».
Поделиться публикацией
Ммм, длинные выходные!
Самое время просмотреть заказы на Фрилансим.
Мне повезёт!
Реклама
Комментарии 92
  • +2
    Вы заново изобрели вот эту штуку: cache.maxsite.com.ua (осторожно, автор сильно увлекается политикой!).
    Ну, или вот эту: wp-cache.com
    • +2
      осторожно, автор сильно увлекается политикой!
      К чему это? По ссылке нет ни слова про политику.
      • +1
        Вторая ссылка — битая (ну или у меня не открывается). Решение по первой ссылке, как я понял, платное. Так что смотреть как оно работает я не буду. Политики не нашел, автор увлекается в первую очередь деньгами.
        • +1

          Способ, описанный в статье, изобретён в плагине WP Fastest Cache лет уж 100 назад. Скорее всего, кто-то неправильно настроил плагин. В нём есть фича, которая сохраняет html страницу целиком при первом обращении и в следующий раз apache (а лучше nginx) отдаёт её как статику.

          • 0
            Как я написал в статье, WP Fastest Cache не сработал. Скорее всего проблема не в плагине, а в самом сайте. Что-то там мешает плагинам кэширования работать нормально. На выяснение причин в тот момент времени не было, пришлось «костылить».
            • 0

              А у вас в какой связке работает веб-сервер? Если только nginx + fpm, то статика не отдается, потому что nginx ничего не знает про нее, нужно править его конфиг.

        • +3
          Всегда считал Wordpress жертвой своей популярности.
          Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности. А все из-за его модульности, сама база написана не оптимально (по сравнению если бы писать скрипт под конкретный функционал, а не под комбайн, который может превратить блог в инет-магазин в несколько кликов). В коде куча лишней логики для обработки этих виджетов.
          Иногда приходится включать жесткий html-кэш средствами nGinx — это единственный выход, если сайт статический.
          • +3
            Я не сторонник WP, но не думаю что вина именно в нем т.к. любой другой даже самый лучший фреймворк который годами переходит из рук в руки и обрастает новыми зависимостями и каждый из разработчиков еще добавит несколько своих оберток к одному и тому же решению… то как бы результат очевиден. Просто проект разрабатывался и администрировался недостаточно качественно, возможно из за экономии средств, а возможно (любая другая причина).
            • +3
              Причины: длинная история, шлейф обратной поддержки, излишняя модульность.
              Это как бы и плюсы, и минусы одновременно.
              Жертвой удобства становится производительность.
              • –1
                Да, если посмотреть, то и самого PHP такие проблемы (как и у любого другого ЯП), приходится за собой тащить груз обратной зависимости.
              • +3

                Проблема в том, что WP не фреймворк

              • +3
                Всегда считал Wordpress жертвой своей популярности. Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности

                Да хоть в 100 раз. Любой программист средней руки может написать узкоспециализированное решение, которое будет летать.


                Это решение будет летать в своей специализированной задаче. И только в ней. Расширение же функционала или переориентация узкоспециализированной системы — обходятся недешево. И что намного важнее — изменения вносятся недостаточно быстро.

                • +1
                  Согласен, стоит ещё упомянуть периодический брутфорс админ-панелей Wordpress.
                  • +1
                    Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности.

                    На битрикс. /sarcasm
                    Не совсем понятно, почему не использовать кэширование nginx, я так понимаю, он там стоял. Как раз и делает подобное, «кэширует страницы».
                    Хотя в данном случае — задача решена, и теперь можно спокойно переделать по уму, сделать бэкапы, себе копию, её оптимизировать или передать wp-разрабам итд. Как аварийное решение — всё правильно сделано.
                  • +3
                    a varnish поставить не пробовали?
                    • 0
                      Нет, не пробовал. По простой причине — не знал о нем. Теперь, знаю и обязательно попробую. Спасибо!
                      • 0
                        Да в общем-то любой веб-сервер или веб-прокси умеет делать ваше кеширование по типу «топор»…

                        У того же Apache есть mod_cache. У nginx кеширование встроено в ngx_http_fastcgi_module и в ngx_http_proxy_module.
                    • +3

                      Спасибо, интересная статья. Запишу в копилку новый термин — "топор". И если в будущем буду искать место, где в WP прикручена некая магия, белая или чёрная, то начну поиск рядом с ob_start().

                      • 0
                        А если пользователь авторизован? Без запросов к БД здесь никак, и все пользователи будут видеть страницу от имени первого авторизовавшегося.
                        • +3
                          Это руководство, как превратить динамический сайт в набор статических HTML страниц :)

                          Если посетители только читают посты на главной, а комментарии на каком-то Disqus, то в принципе нормально для супер быстро обходного решения. С логинами некрасиво, но лучше, чем сайт просто лежал бы. Плагины делают тоже самое, только кешируя отдельные блоки, чтобы не было таких вот косяков, как с именем пользователя.
                          • 0
                            Именно так. Это сайт устроен так, что все пользователи видят по одному URL одинаковую страницу. Комментарии — через соц. сети.Так что потери были невелики, а выигрыш значителен.
                          • 0
                            В данном конкретном случае на сайте нет авторизованных пользователей. Кроме администраторов сайта. Но последние были не в счет.
                          • 0
                            еще можно cloudflare подключить попробовать на какое то время пока не придумаете лучшее решение, он частично может помочь распределить нагрузку. правда там могут повылазить другие проблемы, все зависит от плагинов, настроек самого cloudflare и т.д. Например иногда у пользователей был виден админ бар из кеша :)
                            • 0
                              Как дополнительное решение — возможно. Удивительно, но я о нем даже не вспомнил в тот момент. Но есть шанс на то, что нагрузка упадет недостаточно, если ограничится просто применением CDN
                              • 0

                                Такое бывает, если кеш настроет через задницу. CF понимает ответы сервера.
                                Кеш на cloudflare для сайта с аккаунтами дохлое дело. Спрятат сайт — это оригинальное предназначение.
                                Только время ответа от сервера повышается, так как client -> CF -> server -> CF -> client.


                                Вот кеш сайта без публичных юзеракков — элементарно. Достаточно вынести админку на некешируемый поддомен (тоже за CF) и поставить пароль в nginx.

                              • +1
                                Ко мне обратился владелец одного тематического новостного сайта.… У сайта есть две проблемы.… он сделан на WordPress, причем довольно небрежно.
                                Я, мягко говоря, не очень люблю WordPress. И, что самое плохое в этой ситуации, не очень в нем разбираюсь.

                                Интересно. А хозяин сайта был в курсе этого, когда к вам обращался? И если да, то почему он выбрал именно вас, и, наконец, почему вы взялись за продукт, в котором не разбираетесь и который не любите?
                                • +2
                                  Автор вроде как проясняет этот момент в посте:
                                  И так получается, что из тех, кто не спит в эту субботнюю ночь и что-то понимает в веб-разработке у владельца есть только я
                                  Вполне может быть, что автор и владелец — друзья/знакомые, и произошла ситуация «Лёха выручай, тыжпрограммист».
                                  • +3
                                    А хозяин сайта был в курсе этого, когда к вам обращался? И если да, то почему он выбрал именно вас...

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

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

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

                                    … и который не любите?

                                    Не всегда задачи, над которыми мы работаем, доставляют удовольствие. Иногда нужно набраться терпения и сделать. Это называется профессионализм. Имхо.
                                  • +4

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

                                    • 0
                                      Отказать было невозможно. CDN, как мне кажется, не решила бы проблему в достаточной мере. Хотя, честно говоря, я даже не успел об этом подумать. Что касается Varnish — я о нем лишь слышал краем уха и забыл. Обязательно поиграюсь с ним. Хостер «проснулся» для решения проблемы с переходом на другой тариф только с утра, в 9.00 по Москве. Как, собственно и обещал: я выяснил это в первую очередь.
                                      • +1

                                        На cdn можно настроить, какие странички считать статикой и кэшировать. Собственно можно так закэшировать весь сайт — https://blog.cloudflare.com/introducing-pagerules-advanced-caching/
                                        А отказаться можно всегда. Ваше описание клиента мне лично говорит о его неадекватности и, вероятно, прижимистости.

                                    • +3
                                      Оба плагина с которых начался пост с озвученной в продолжении поста задачей справляются прекрасно. Вероятно проблема была в их конфигурации
                                      • 0
                                        Скорее, проблема в том, как сайт сделан и поддерживался. В любом случае, как мне кажется, подобные решения (плагины для кэширования) должны работать «из коробки» с настройками по умолчанию хотя бы на условные 50%. В данном случае этого не происходило. Смена настроек на рекомендуемые в различных обзорах/инструкциях и т.п. тоже не дает особого улучшения. Это я проверил уже позже. Думаю, если разобраться с сайтом, то они будут прекрасно работать. Но на разбор у меня просто не было времени.
                                        • 0
                                          Из коробки они раделяют авторизованных и неавторизованных и включают самый простой вариант файлового кэша. Если будет возможность проверить, гляньте что они там создают в файловом кэше своём на этом конкретном сайте.
                                      • +10
                                        Нормальное решение:
                                        Ставим xhprof/xdebug (strace, если хочется тёплого лампового свечения сисколов), рандомно включаем на 2-3 страницах, видим в чем проблема.
                                        Обычно варианта три
                                        1. Очень большие задержки от файловой системы. В 90% случаев не чистится файловый кеш(чистим, проверяем настройки плагинов кеширования и на всякий случай ставим соответствующий крон find… -delete раз в час для файлов старше CACHE_TIME*2)
                                        2. Очень большие задержки по сети (конкретный плагин который делает запросы по сети, а удалённый ресурс тормозит). Обычно таких плагинов 1-2, после их отключения и/или впиливания кеширования конкретно в них всё работает.
                                        3. Конкретный плагин который кладёт БД. Смотрим запросы в mysql -e 'show full processlist', проставляем индексы ну или запиливаем кеш где логически возможно.
                                        4. Если ни одно из вышеперечисленных, убеждаемся что машине тупо не хватает процессора, добавляем немного ядер и спокойно изучаем проблему более детально.

                                        Эти 4 пункта покрывают 99% случаев. Остальной 1% это самое интересное и выходит за рамки этого комментария.

                                        Когда работал в хостинге решал такие проблемы десятки раз, на потоке диагностика занимала 5-10 минут. И что WP, что битрикс, что друпал всё одно примерно и проблемы одинаковые.

                                        Честно говоря, это всё общетехнические методы, которые мне постоянно помогали и не только в php-приложениях.

                                        PS шаг 0. Смотрим на htop и понимаем чем конкретно занимается машина и чего ждёт вообще.
                                        • 0

                                          Отличный комментарий.


                                          Еще по делу могу добавить к пункту 3 — помогает очень сильно объектное кеширование. Ставится redis + плагин из репо для его поддержки, и можно перестать думать некоторое время о скорости базы.

                                          • 0
                                            За «пункт 0» — спасибо, как-то не подумал. С остальным согласен частично. Сейчас объясню почему.

                                            на потоке диагностика занимала 5-10 минут.

                                            Диагностика — это хорошо, но сколько бы заняло решение? А именно оно тут требовалось в первую очередь. Я согласен, что данному конкретному сайту требуется диагностика и последующее решение «всплывших» проблем. Но делать это на «падающем» сервере — с моей точки зрения не совсем правильно. Надо сделать локальную копию и далее сидеть, думать, разбираться. Это детективная работа, на которую, повторюсь, времени не было.

                                            А теперь по пунктам:

                                            xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.

                                            1) Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.

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

                                            3) Это и есть корень зла в данном конкретном случае. На нормальное решение этих проблем уйдет довольно большое количество времени.

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

                                            • +1
                                              Спасибо за комментарий и подробную аргументацию.

                                              Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.

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

                                              Если причина конкретный функционал, проще всего выполнить его отключение штатными средствами. Это самый понятный для владельца сайта и для исполнителя путь.

                                              >> Диагностика — это хорошо, но сколько бы заняло решение?
                                              В 80% случаев 5-15 минут.

                                              >> xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
                                              Не соглашусь категорически.
                                              На живом, и именно в момент падения (иначе как узнать реальную причину?). Оверхед если не писать каждый запрос около 2%(xhprof). Конечно, писать выборочно по куке/GET-параметру, собрать 10-20 образцов, отключить.

                                              >> Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
                                              Удаление заведомо просроченного кеша это правильный механизм. Кеш должен иметь TTL, но файловый кеш в условиях шаред хостинга, это не redis.

                                              Удаление по крону это резервный механизм который много раз спасал. Кейс конкретный: плагин WP обновился, поменялись ключи кеширования и почему-то отключилась автоматическая очистка. Один из плагинов (я уже забыл название и версию) вообще никогда не чистил просроченные элементы по которым нет попаданий. Третий тёр файлы, но не тёр пустые папки.
                                              Если бы все плагины имели корректно работающие механизмы очистки, это конечно же было бы лишним.

                                              >> 2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему.
                                              Часто суть проблемы проще, чем кажется на первый взгляд.
                                              В случае в внешними ресурсами даже часто править код не надо. Достаточно просто (на время до реализации нормального решения или отлипания внешнего ресурса*) через /etc/hosts сделать так чтобы проблемный внешний ресурс резолвился в, к примеру, 127.0.0.2, а соединение с ним быстро падало (а не после 10 секунд ожидания).
                                              Конечно, отключение плагинов всегда согласовывается. У меня очень были случаи когда плагин реально несущий. Большинство поставщиков подобных проблем это плагины курсов валют, погоды, rss/twitter и прочая подобная ерунда. Особняком стоят биржи ссылок, но с этим добром отдельная история.

                                              >> 3) Это и есть корень зла в данном конкретном случае
                                              Да, такие проблемы иногда не решаются простыми способами. Но посмотрите внимательно на БД, вдруг после череды обновлений в таблицах нет в сравнении с новой чистой установкой нужных индексов или чего-то подобного?

                                              Так или иначе, успехов в делах и новых интересных задач!

                                              *) в зависимости от уровня перфекционизма.

                                              • +2
                                                Спасибо и вам, я кое-что узнал и от вас.

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

                                                >> xhprof/xdebug — согласен, ляпнул не подумав.

                                                За то, что плагины WP работают как придется и точной уверенности в том, что именно и как они делают нет, я их и не люблю.

                                                Про внешние запросы — соглашусь, но мне все-таки не нравятся такие решения. Плюс в данном случае дело не в них.

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

                                                И напоследок, самое забавное. Вам, думаю, понравится. Я скачал чистый дистрибутив той версии WP, что стоит на этом сайте. И сделал поиск изменений. В тех местах, где, по идее, хранятся «системные» файлы WP. Его «ядро». В которых, как мне кажется, вообще не должно быть правок. В них кто-то ковырялся. И сильно. Как, думаю, вы понимаете, это сразу ставит под сомнение штатность работы всей системы. И, соответственно, эффективность нормальных решений.

                                                Вам тоже всяческих удач!
                                                • 0
                                                  Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.
                                                  Особенно замечательно выглядит такой подход у врачей, когда пациент стонет от боли. Понятно, что можно потерять симптоматику, но все-таки лучше (с точки зрения пациента) вначале обезболить, а уж потом искать причину болей. :-)

                                                  Мне как-то кажется, что пары часов ожидание кетанова в приемном покое вам хватит, чтобы понять, как оно выглядит с точки зрения пациента.
                                                  • 0
                                                    Спасибо, посмеялся.

                                                    А по сути дела тут важно примерно понимать где проблема. Ну вы же не пойдёте к стоматологу, если у вас болит нога или не будете заливаться анальгетиками при занозе в руке.
                                                    А с сайтом непонятно, он, к сожалению(или к счастью пока), не говорящий.
                                                    • +1
                                                      Ну я тоже не настолько говорящий, чтобы отличить почечную колику от печеночной или их обоих от атипичного аппендицита.

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

                                                      В рассматриваемом примере критично время. Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте. Но… «вскрытие показало, что пациент умер от вскрытия».

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

                                                      И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.

                                                      В пределе — представьте, что каждую лишнюю (по сравнению с брутто-методом) минуту простоя вам оплачивать из своего кармана?

                                                      А что хочется всегда найти причину и исправить именно её — это правда. Особенно когда остались последние 17 минут работы ноута, а ты лежишь в канаве у полотна РЖД и пригибаешь голову от пролетающих мимо «сапсанов». Ну на то и опыт, чтобы дать себе по рукам и сделать брутто-способом.
                                                      • +2
                                                        Поверьте, ожидание в приёмном покое у меня тоже было.
                                                        Я проклял всё. Но в принципе я уже потом всё обдумав понял что могло быть и хуже.

                                                        > Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте

                                                        Мой опыт потокового решения подобных проблем с популярными CMS (я думаю что это точно больше сотни кейсов только по WP) говорит о том, что диагностика важнее. Коллеги даже для SLA считали — в среднем 7 минут диагностика, полное решение 10 (разница небольшая, так как в основном даже правки по коду не нужны).

                                                        > И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
                                                        Не всё так однозначно.
                                                        Конечно, впилить костыль в результате которого закешируется страничка с админским айдишником сессии это намного лучше.
                                                        «Проблема решена — решена. А то что теперь рандомный пользователь может делать с сайтом что угодно, об этом в задаче не было.»

                                                        Я сейчас работаю с ресурсом(Alexa top 2k, alexa_RU top 100), где минутный простой стоит очень дорого, а косяк в результате которого будут слиты наружу пользовательские данные — ещё дороже.

                                                        Все такие истории это баланс скорости и рисков. Вот и всё.

                                                        ЗЫ ах эти времена с кнопочными телефонами и midp-ssh
                                                        • 0
                                                          Если вы гарантируете SLA и SLA устраивает заказчика — разумеется, лучше лечить причину. Но у меня — совсем не сайты. Да. конечно, часто кажется, что можно найти и исправить причину за час-два. И двух третях случаев — это правда. А в остальных…

                                                          Ну как пример. Одна из ошибок, вылезших из генеральского эффекта, была найдена вообще через полгода (недели две чистого времени на ловлю). После обнаружения было рассчитано, что шансы на проявление — 1 раз в 3 года. Вылезла она на стенде за пару часов до перехода к опытной эксплуатации. Вы думаете стоило ждать её нахождения и ликвидации? :-) А брутто-методом я её закрыл за 5 минут.

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

                                                          А впилить вторичную ошибку при брутто-методе — шансов меньше. То есть та ситуация, когда лекарство хуже болезни — оно больше при лечении причин. Брутто-методы обычно как-то безопаснее.

                                                          ЗЫ ах эти времена с кнопочными телефонами и midp-ssh
                                                          Дико туплю — это вы к чему? Заодно — объясните, почему не стоит обезболивать занозу — это я тоже не понял.
                                                          • 0
                                                            Кушать кетанов при занозе это очень странно, по двум причинам: 1. чаще всего проще вынуть и без врача и она хотябы перестанет мешать дойти до врача и вызывать боль при прикосновении 2. есть местные антибиотики.

                                                            >> Дико туплю — это вы к чему?
                                                            Ваш комментарий про полевые условия как раз напомнил мне «те времена».
                                                            • 0
                                                              У нас высокоточный GPS, так что полевые испытания идут регулярно и в очень интересных местах.

                                                              Логика у вас забавная, судя по вашим текстам, вынимать надо обязательно с болью. Или с чем-то, чего дома обычно не бывает, типа рогатой ампулы с четырехлористым углеродом. :-) Мы уж лучше по старинке. Если болит так, что нужен кетанов, то сначала обезболить, потом к врачу.
                                                          • +1
                                                            Хм. На самом деле кэширования страниц с админскими данными не было. И, более того, не могло быть.
                                                      • +4

                                                        В ITSM это два разных процесса: управление проблемами (problem management) и управление инцидентами (incident management). Задачи этих процессов разные, и частенько даже противоречивые. Поэтому заниматься ими должны, как правило, разные люди. Если такое не получается, то эти функции должны быть по крайней мере разнесены во времени.


                                                        Очень коротко и грубо

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


                                                        Задача управления проблемами — сделать так, чтобы инциденты в дальнейшем не возникали. Ключевая метрика — количество инцидентов в единицу времени (с учетом тяжести инцидентов).


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


                                                        Пример (плохой, но первое, что пришло в голову):


                                                        Отчет команды управления инцидентами:


                                                        1. Описание инцидента: сервер перестал отвечать на запросы.
                                                        2. Выявленная причина: HDD забит логами.
                                                        3. Меры по устранению: удалены файлы логов.
                                                        4. Результат: работоспособность сервера восстановлена.
                                                        5. Время устранения инцидента: 3 минуты.

                                                        Отчет команды управления проблемами:


                                                        1. Причина возникновения инцидента: установить невозможно, т.к. логи были удалены во время устранения инцидента.
                                                        2. Выявленная проблема: Периодические отказы в обслуживании (тут должны быть подробности).
                                                        3. Анализ причин проблемы: не выполнялся, см. п.1.
                                                        4. Рекомендации по устранению проблемы: не имеется, см. п. 1.
                                                        5. Прочие рекомендации: выделить для ведения логов отдельную файловую систему/отдельный сервис. При невзможности, команде устранения инцидентов перед удалением сохранять логи на внешний носитель и прикладывать к отчету.
                                                  • +2
                                                    +1 еще и на php сэкономить можно таким образом.
                                                    • 0
                                                      Да, это решение. При условии (если ошибаюсь — поправьте), что нигде в коде не открывается сессия. Что нужно искать и проверять. А если такое есть — то исправлять и тестировать. Не уверен, что такой подход был бы быстрее. Про «правильность» я ничего не говорю — не до того было. Сейчас, за чашкой чая можно, конечно, выбрать оптимальный вариант. Но за вариант — спасибо!
                                                    • +2
                                                      Каждый раз читая заметку, «я не умею готовить WP, но вот этот костыль мне помог», недоумеваю, почему не прочитать нормальные инструкции как настроить WP, чтобы он держал любой более менее разумный траф.

                                                      При чем начать можно с базовой статьи: codex.wordpress.org/High_Traffic_Tips_For_WordPress

                                                      У меня 100К посетителей и более 1Tb трафа в день WP держит без намека на перегрузку.
                                                      • +2
                                                        Странно читать подобные комментарии. Где характеристики сервера? Какое ПО используется? И тд.
                                                        • –2
                                                          Комментарий про это:
                                                          Вторая проблема — он сделан на WordPress
                                                          Я не считаю это проблемой. Есть сайты на WP вроде www.bbcamerica.com с гораздо большей нагрузкой, чем мой…
                                                          • +2
                                                            Как вы тактично ушли от ответа) Ну да ладно.
                                                        • +1
                                                          Ну, базовая статья, если коротко, говорит: «не забудьте правильно подобрать и настроить сервер. Поставьте плагин кэширования. Следите за сайтом». Все это прекрасно, но в моем случае это было «пить «Боржоми», когда почки отказали». Это должны были знать, в первую очередь, те, кто довел сайт до его текущего состояния. Разумеется, сайту требуется оптимизация.

                                                          То, что ваш проект держит 100К посетителей в день — это хорошо. Но, если не секрет, на какой конфигурации сервера?
                                                          • –1

                                                            В вашем случае я бы действовал так:


                                                            Включил в WP режим обслуживания.
                                                            Поставил на выбор wp-super-cache или w3-total-cache
                                                            Включил в кеширование в статитку.
                                                            Выключил режим обслуживания.

                                                          • 0
                                                            Может потому что 99% проектов на вп это чистый говнокод с кучей костылей? Речь же не идет о приготовлении, вопрос в том как из горелой курицы сделать хорошую и вкусную, а это практически невозможно ;) А вообще делать на вп крупный проект в любом случае один геморой и гораздо эффективнее взять более серьезный инструмент
                                                        • +4

                                                          Вы поставили плагин для кеширования, и даже не разобрались как именно он кеширует. Все популярные плагины кеширования для WP имею 2 режима кеширования: статическое и динамическое. Статическое предполагает как раз описанный вами способ с хешированием и прочим, но требует либо Apache(внесение изменений в .htaccess), либо правку конфига Nginx. Динамическое кеширование как раз работает так, чтобы какой-то фарш можно было запустить на определенном уровне WP(например, логику GeoIP), и только затем отдача такого же статического контента. Второй способ более ресурсоемок, но все равно достаточно быстрый. Первый, когда отдается статика, понятное дело быстрее.


                                                          Чаще всего все тормоза WP связаны с большим количеством кривых плагинов. Возможно, какой-то плагин вообще ломал весь флоу в процессе кеширования, возможно просто вешал БД.


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


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


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

                                                          • 0
                                                            С общими принципами кэширования я, вроде бы, знаком. И рассчитывал, что упомянутые мной плагины быстро реализуют на сайте эти принципы. Чего, однако, не произошло. Причины — дело второе. На игры с настройками времени особенно не было: надо было оперативно решить проблему с наименьшими потерями. Кстати, как я потом уже проверил, переключение разных режимов кэширования в настройках этих плагинов ничего не дает. Думаю, причина в том, что где-то во внутренностях есть большой, сделанный кем-то, кто обеспечивал работу проекта ранее, косяк. Который, собственно, мешает нормальной работе этих плагинов. Его еще нужно найти. Опыты, как мне кажется, желательно ставить на локальной копии, а не на живом сайте с десятками тысяч посетителей.

                                                            «Кривых» плагинов там установлено море. Не мной. Более того, я даже примерно не знаю зачем установлены многие из них. Основная общая проблема — переизбыток запросов к БД, да.

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

                                                            Про то, что нужно разумно подходить к разработке, а всякие доработки по принципу «работает же!» — зло, я абсолютно согласен.

                                                            • 0
                                                              Имхо, почти нулевой уровень вхождения не проблема, а киллер-фича WP, как и PHP в целом.
                                                            • +1

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

                                                              • 0
                                                                Примерно так и оказалось
                                                              • –12
                                                                Походу НЛО что-то не то кушало на НГ, отравилось и понаприглошало всякую х… мнэ… молодых и бурно развивающихся авторов.
                                                                • +3
                                                                  И вам, дорогой мой, всего хорошего!
                                                                  • +5
                                                                    Ага, и тут выходите Вы с 0 публикаций и кармой -28, весь в белом и всех разоблачаете!
                                                                    • +1
                                                                      Ну, правда, посты «я ничо не умею в этой теме, и тут надо что-то сделать, я что-то сделал, что придумал, и вот, смотрите, написал про это пост на Хабр!» это все же как бы совсем не уровень Хабра.
                                                                      • –3
                                                                        Особенность исчисления кармы на хабре в том, что оно не стимулирует писать мало, но хорошо.
                                                                        Зато стимулирует писать много в стиле «как я научился печатать буквы и побежал становиться Редактором GT».
                                                                        У меня были статьи, но один неудачный комментарий — и все труды насмарку.
                                                                    • 0
                                                                      WP по умолчанию хранит черновики постов в базе и еще кучу всякого мусора.
                                                                      Возможно стоит немного почистить и саму базу в 2Гб
                                                                      • +1

                                                                        собственно nginx fastcgi cache + fastcgi_cache_lock on; все решает.
                                                                        А как твик для базы — перевести на innodb (если там старая myisam), далее настроить движок innodb в конфигах MariaDB & задать ключ wp_options для autoload, так как это поле почему-то не ключевое, но все время в запросах и там всего 2 значения.

                                                                        • 0
                                                                          Вы не смотрели в сторону кеширования на стороне именно веб-сервера (даже на хабре были посты, вроде такого)? Конечно, готовить кеш надо уметь, но, если не очень разбираться в WP, вам будет проще сделать кеш именно на веб-сервере.
                                                                          Второй вариант — то же сделать через услуги сетей CDN, того же айри (не рекламы ради, просто общался с положительным результатом). Их работа как раз сделать так, чтобы до вашего сервера прилетало меньше запросов, а больше — отдавалось из их кешей.
                                                                          • 0
                                                                            Вряд ли статика сильно нагружает сервер. Проблема в статье как раз больше про динамику, из-за которой сайт тормозит.
                                                                            • +1

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

                                                                          • 0
                                                                            было интересно почитать, спасибо.
                                                                            • –3

                                                                              Повествуется как батин жареный суп.

                                                                              • 0

                                                                                "Когда-то давно, когда я читал мануал к PHP я встречал там функцию «ob_get_contents()». Я никогда ей не пользовался, но тут она пригодилась." — что сказать если даже не читая документации к языку человек умудрился каким то чудом производительность улучшить и почему взялся что-то оптимизировать вобще.


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

                                                                                • 0
                                                                                  Хороший пример из жизни об использовании ob_get_contents() и exit(), спасибо!
                                                                                  • 0

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

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

                                                                                      Здорово то, что автор оперативно решил задачу в live-режиме, это здорово!
                                                                                      • 0
                                                                                        Пост шикарный! Всегда интересны истории фаст-фиксов на огне!)
                                                                                        Пиши исчо!
                                                                                        • +1
                                                                                          плагины эти, о которых вы писали в начале статьи (я просто не читал ее до конца, хочу по этой теме сказать) — fastcache & supercache — они держат миллионы хитов в сутеки. да какие сутки, в минуты! при правильнрой настройке естественно.
                                                                                          потому что они кешируют сайты в статику (в html, можно сразу пожатый), а там уже апач может выдать сотни тысяч, nginx миллионы…
                                                                                          из всех этих посетителей реальная динамика нужна десятке, в худших случаях сотне пользователей. они определяются по куке и их мы шлем бекенд, парралельно они же формируют в кеше html-ки, которые и отдаются потом обычным «юзерам» (сотнями тысяч/час).
                                                                                          подобные плагины есть в любой более-менее вменяемой cms… и изучать ее, часто, даже и не нужно — достаточно понимать основные принцыпы…
                                                                                          бывают конечно и тяжелые случаи — форумы, активно генерируемые камменты к постам и т.п. и даже этих, иногда, можно кешировать хоть на 15 сек — уже профит огромный…
                                                                                          не знаю, я наверное повторился… но тем не менее…
                                                                                          • 0
                                                                                            Интересно расписал, завис на картинке рабочего стола: искал дубли иконок, тип аля «Найди пару»
                                                                                            • 0
                                                                                              Автор молодец! Для данной ситуации и при текущем наборе инструментов я бы поступил так же!
                                                                                              • 0
                                                                                                Любопытная статья. На месте автора мог оказаться админ любого другого контент-ориентрованного сайта. Если, предположим, сайт был бы в разы популярнее? Или написан не на WP?..
                                                                                                Я для таких случаев знаю два решения: Akamai и Auto Scaling у Амазона. Первый — мощный кэширующий сервис, предоставляющий, в простейшем случае, все то же кэширование статического контента. Ну и тьму других плюшек e.g. защита от ddos, FTP хранилища, фильтрация по geoip признаку и все в таком же духе.
                                                                                                Со вторым понятнее: выросла нагрузка — ферма виртуалок тоже выросла, нагрузка упала — ферма уменьшилась.
                                                                                                Интересно было бы узнать, к автору часто по этой проблеме обращаются?
                                                                                                • +1
                                                                                                  // написан не на WP

                                                                                                  если сайт написан на PHP — описанная логика решения сработала бы на любой CMS
                                                                                                  в этом ценность поста — помнить о минималистичном боевом кэшировании с помощью ob_get_contents
                                                                                                • +2
                                                                                                  Автор молодец, что справился и решил проблему быстро, как и заказывали. Плохо, что к решению проблемы привлекли неспециалиста… да и вообще там много стратегических ошибок хозяина сайта, которые привлекли к пожару, который пришлось тушить в авральном порядке.

                                                                                                  Но. В итоге я проголосовал против статьи. Ничего личного, все молодцы — но я хотел бы на этом сайте читать про умные решения и не очень хочу читать про то, как неспециалисты тушат пожары. И может быть я пойду против мнения большинства, но мне жаль видеть эту статью в топе.
                                                                                                  • +1
                                                                                                    В идеальном мире адекватный заказчик привлек бы специалиста, и дал бы ему время, хостинг, и любой другой необходимый ресурс, которых в идеальном мире достаточно.
                                                                                                    В реальном мире постоянно находишь себя в ситуациях нехватки знаний и/или времени, и необходимостью выбора из плохих вариантов.
                                                                                                    • +2
                                                                                                      Плохо, что к решению проблемы привлекли неспециалиста...

                                                                                                      так судя по описанию внутренностей сайта, это основная стратегия заказчика)))
                                                                                                    • +1
                                                                                                      Мне очень понравилась статья. Я сам был в подобной экстренной ситуации. Когда сайт упал в ненужный момент. И пришлось поднимать собственными костылями.
                                                                                                      Автор молодец.

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