Итак, мой сайт был заблокирован хостером из-за возросшей нагрузки на сервер. Сайт на движке wordpress.

Для начала я полез на сайт http://tools.pingdom.com/, чтобы оценить время загрузки каждого файла, которые составяляют страницу моего сайта. Это очень удобная тулза для определения узкого места сайта с точки зрения загружаемых файлов. Вот как выглядел мой сайт до оптимизации:
perfomance

Желтая часть полоски — время между отправкой запроса сайту и коннектом к серверу. Как видно, проблем с коннектом нет.

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

Синяя часть — время между началом передачи файла и концом его передачи, т.е., скорость обмена данными между сервером и клиентом. Тут тоже всё довольно ожидаемо и понятно. Немного бОльшее время потрачено на обращение к гугловому скрипту (адсенс), но, я думаю, это не существенно.

Прежде всего я начал выяснять, что это за урл, который хавает половину загрузки страницы. Во1, папки mint в указанном месте я не обнаружил. Во2, этот урл был прописан в хедере темы! Удалил его нахрен :)

Дальше я протестировал страничку с одним из постов на сайте, вот что у меня вышло:

perfomance2

Как видно, подозрительного урла, жрущего кучу времени уже нет, и на выходе мы получаем время 4.3 секунды вместо 6, что уже неплохо :)
Дальше идут файл JS, CSS и картинки. В принципе, всё это достаточно мелко и ожидаемо. Осталось разобраться с главным виновником тормозов — генерации самого html-кода движком WordPress`а.

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

perfomance3

Запросы отсортированы по времени исполнения, и видно, что самый тяжелый запрос — от плагина related posts. Вообще, кликая по разным постам я выявил два самых жрущих запроса — вышеназванный и еще один, который необходим для работы движка и является одним из самых главных запросов (обращение к wp_terms, который на скрине выше идёт вторым). Так как практически всегда плагин related posts выдает в качестве похожих постов посты с одними и теми же метками, я решил убрать этот плагин, заменив его на вывод последних пяти постов с теми же метками, что и у текущего поста. Это действие, во1, убрало жрущий запрос, во2, убрало еще 5 (ептваю, ПЯТЬ!) запросов. Вот, оказываеца, какой жырный плагин, этот related posts.

Далее, я начал анализировать все запросы к БД, и нашел довольно странный запрос, идуший от плагина all-in-one-SEO-pack:

SELECT option_value FROM wp_options WHERE option_name = ‘aiosp_donate’ LIMIT 1

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

add_option(«aiosp_donate», 0, ‘All in One SEO Pack Donate’, ‘no’);

и закомментировал её. И еще одним запросом к БД меньше!

После отключения related posts и еще одного запроса, html стал генерироваться всего за 1.8 секунды! Скрины приводить не буду, лениво :)

Далее идут более стандартные попытки оптимизации, путём различных плагинов.

Я заменил файл русификации «ru_RU.mo» на «ru_RU_lite» (данный файл есть в сборке кактуса, описание процедуры на сайте Лекактуса).

Потом заоптимизировал таблицы с помощью плагина Optimize DB. Насколько я понимаю, он делает mysql-команду OPTIMIZE TABLE для всех таблиц движка. В принципе, тож самое можно сделать и напрямую, через phpmyadmin или зайдя на сервак. Но как-то чрз плагин удобней, да и при работе сайта плагин никак его не грузит.

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

Далее, я посмотрел на сгенерированный html страницы с постом, чтобы определить ненужные, левые и подозрительные html-конструкции, строчки и тэги. Накуй убрал пинги и треки, link archiv`ы, пустые строки, комментарии, информацию о версии движка.

Следующим этапом была ревизия темплейтного кода, оказываеца в темплейте были функции, которые генерировали SQL-запросы, НО при этом ничего не выводили. Также убрал ненужные конструкции, где проверялись заведомо правдивые или заведомо ложные условия.

Ну и в самом конце — установка главного нагрузко-снижающего плагина кэширования. В сети наиболее известны два подобных плагина — WP Super Cache (WP Cache2) и WP Hyper Cashe. Я остановился на последнем, почему — говорят, он лучше :)

После всех изменений вот что у меня получилось:

perfomance4

По-мойму, намного лучше, чем было :)