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

Прожорливость WordPress

Как выяснилось, чтобы сайт на WordPress начал создавать недопустимую нагрузку на процессор сервера, много не надо: достаточно 15-20 раз подряд (с паузой не более 0,75 секунды) кликнуть по одной и той же ссылке или просто открыть с предельной скоростью 15-20 страниц сайта во вкладках или же понажимать F5 в браузере десяток раз.

Если недопустимой нагрузкой провайдер называет уже 5 %, то таким вот нехитрым кликаньем, если очень постараться, можно вызвать нагрузку, если верить логам, до 28 процентов (!!!). А теперь представим, что кликать начал не один пользователь, а два? Да, проблема актуальна только для виртуального хостинга, да и то есть мысли, как они могли бы это оптимизировать… Но тем не менее проблема существует.

Также выяснилось, что с каждой новой версией WP становится все прожорливее. Скажем, если версия 2.3.3 потребляла менее 10 Мбайт памяти, то 2.7.1 — не менее 20.

Практика показывает, что мой сайт с кучей виджетов иногда потребляет до 45-55% процессорного времени. Откуда же берутся такие цифры?

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

Скажем, на одно отображение страницы WordPress 2.8 тратит около 19 Мб памяти и 1 секунду времени. Это значит, что в течение 1 секунды, всем остальным клиентам вашего хостинга недоступно примерно 25 мегабайт памяти. Предположим, что у Вас – 100 посетителей в сутки и в среднем они осуществляют 3 просмтра страницы. Значит, Ваш сайт расходует где-то 300*25 Мбайт памяти в течение 300 секунд. В масштабах целых суток – все нормально.

Но предположим, что у сайта начинает расти посещаемость (до 150 человек в сутки), или же Вы установили какой-нибудь супер-пупер новый плагин, и потребление памяти WordPress возросло до 30 Мбайт. Таким образом, потребление ресурсов хостера выросло примерно на 50%. Если хостер сочтет, что Вы потребляете слишком много памяти и процессорного времени за те деньги, которые Вы ему платите – Вам будет отправлено предупреждение о возможном отключении сайта и предложение сменить тарифный план.

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

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

Основные причины перегрузок

Основные причины, по которым блог очень сильно нагружает хостинг:

  1. Вывод последних комментариев (обычно ставят на отображение 10 последних – а это дополнительные 10 запросов к БД)
  2. Вывод последних новостей в специальном блоке (нет смысла в этом блоке, если на главной странице почти у всех и отображаются 5-10 последних новостей)
  3. Вывод самых комментируемых новостей (опять же лишние запросы…)
  4. Большое количество совсем не нужных установленных виджетов.
  5. Много опять же не нужных установленных плагинов.
  6. Множественные лишние запросы в самом шаблоне, которые можно заменить на статическое содержимое.

Методы борьбы с нагрузкой

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

Часто проблему можно решить путем включения кэширования. Например, для WordPress это может быть плагин WP-SuperCache. В ModX на нужных страницах можно поставить флажок “кэшируемый документ”. В Drupal это делается в меню “Настройка сайта –> Производительность”. Для Joomla можно скачать PageCache.

Плагины кеширования для WordPress: Это WP-Cache, WP Super Cache, Hyper Cache, WP File Cache.

WP-Cache

В принципе — WP-Cache версии 2.0 — разработан в 2005 году и с того времени последние обновления производились в 2007 году, так что использовать наверное не желательно в силу все же больших изменений в самом двигателе и выхода версии 2.7.

WP Super Cache

Самый распространенный в данное время плагин. Автор плагина — Donncha O Caoimh. Страница плагина — http://ocaoimh.ie/wp-super-cache/.

WP Super Кэш является плагином статического кэширования для WordPress. Он генерирует HTML файлы, которые обслуживаются непосредственно Apache без обработки сравнительно тяжелых PHP скриптов. С помощью этого плагина вы существенно можете ускорить ваш блог WordPress.

Недостатки:

— требует достаточно большое дисковое пространство для хранения данных кеширования;
— имеются неустраненные программные ошибки (пока), которые часто приводят к “падению” сервера (почитать можно здесь — ;
— достаточно сложный в установке (требует редактирования wp-config.php и .htaccess) и настройке.

Hyper Cache

Принцип работы практически одинаков с WP Super Cache. Тоже создание статических страниц, их хранение и выдача при обращении к сайту.

Сайт автора плагина — , домашняя страница плагина — .

Недостатки:

— тоже много памяти под кеш страниц;
— непонятная обработка страницы 404 и укладка в кеш;

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

WP File Cache

Это тот плагин, который мне понравился и который могу Вам порекомендовать. Поэтому в отношении его больше о преимуществах. А они следующие:

— реализация долговременного кэширования на уровне запросов;
— полная совместимость с интерфейсом класса WP_Object_Cache WordPress;
— использование памяти под сессионный кэш для увеличения производительности;
— сессионное кэширование часто изменяющихся объектов;
— хранение настроек в коде плагина;
— изначально на русском и английском языках;
— русский автор, соответственно русская поддержка и иструкции.

Автор плагина — Владимир Колесников, домашняя страница плагина — .

О тестировании производительности кэшей можно почитать здесь http://blog.sjinks.pro/wordpress/683-wp-supercache-vs-hypercache-vs-w3-total-cache-vs-maxsite-cache/ и в продолжении статьи

Краткие выводы: на грамотно настроенном сервере лидирует WP Super Cache — и по скорости, и по создаваемой нагрузке.

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

Плагин DB Cache Reloaded является инструментом, обеспечивающих динамические кэширование запросов к базе данных. Работа этого плагина базируется на совершенно иных, отличных от плагинов статического кэширования, принципах, и позволяет существенно увеличить скорость загрузки блога и снизить нагрузку на хостинг.

Каждый раз, когда формируется страница блога, идут запросы к базе данных, посылаемые темой, виджетами, плагинами. DB Cache Reloaded кэширует эти запросы, направляя их в дальнейшем не в базу данных, а в кэш, доступ к которому более быстрый. В итоге количество обращений к базе данных снижается в несколько раз (в моем случае, с 25 до 5). Это снижает загрузку процессора и использование оперативной памяти — снижается общая нагрузка на хостинг, уменьшает время генерации страниц блога. Настройки плагина минимальны, есть код, который можно вставить в footer.php для отображения времени загрузки блога, количества обращений к базе данных и объема потребляемой оперативной памяти.

Скачать DB Cache Reloaded

Если простым кэшированием не обошлось – нужен взгляд профессионала. Необходимо найти “плохой” плагин или модуль, и обновить, починить или заменить его. Навскидку – могу порекомендовать отключить модули статистики и использовать вместо них счетчик LiveInternet или Google Analytics. Полная оптимизация сайта может занять огромное количество времени (и денег), так что устраняйте проблемы по мере их возникновения :)

Блокировка запросов на новые версии

Движок WordPress устроен таким образом, что при каждом входе в административную часть он смотрит, не обновился ли какой-нибудь плагин. Как он это делает? В каждом плагине прописана его страница, обычно это раздел в каталоге плагинов на сайте wordpress.org. Заходя туда, он сравнивает версию, установленную в у вас с той, что находится на сайте плагина. Если там более новая, то он предлагает обновить плагин.

То же самое он делает и по отношению к самому себе – каждый раз проверяет, не сделали ли разработчики WordPress новую версию. Понятно, что такая работа отъедает у вашего сайта и так те немногие мегабайты памяти, которые выделяются провайдером на его функционирование.

Я не привык часто обновлять плагины, и, один раз подобрав их и настроив, предпочитаю больше с ними не возиться, исповедуя принцип “работает – не трогай!”. Поэтому мне достаточно три-четыре раза в год проверять, не вышла ли новая версия какого-нибудь, плагина, а на остальное время отключать эту функцию.

Раньше я делал это руками, исправляя конфигурационный файл. Так продолжалось, пока Калинин Иван не сделал плагин, который на лету лишает WordPress проверки на обновление плагинов. Заодно он отключает и сам WordPress от проверки на обновления. Называется этот плагин Блокировка запросов на новые версии. Работает плагин просто: активировали – работает, не активировали – не работает.

Автоматическое управление версиями (ревизиями)

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

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

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

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

Оба плагина хороши прежде всего тем, что не надо лезть в код и редактировать его вручную. К тому же, деактивация плагинов приводит к восстановлению настроек по умолчанию. Это не единственные варианты ускорения работы WordPress, но они – самые доступные.

Плагин WP-Optimize

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

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

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

Скачать WP-Optimize

Анализ «кривизны» вашего сайта

Для того, чтобы проверить сколько же запросов к базе данных происходит при загрузке той или иной страницы вашего сайта вы можете воспользоваться известным плагином WP Tuner — скачать плагин WP Tuner. Плагин устанавливается стандартным способом, а именно:

  • распакуйте архив wptuner.zip, используя ftp-менеджер подключитесь к вашему сайту и загрузите папку wptuner в папку с плагинами wp-content/plugins/ на сервере
  • войдите в админку wordpress и выберете вкладку «Плагины»- «Inactive»
  • найдите строку с плагином WP Tuner и активируйте его
  • После активации, WP Tuner должен прописать в wp-config.php свои настройки. Для этого надо временно открыть этот зайл на запись с правами 666 или прописать небольшой кусок кода вручную.
  • Если код автоматом не прописался, об этом скажет сам плагин в виде ошибки и её описания.

Теперь можно зайти в админку вашего блога и ознакомиться с настройками плагина WP Tuner. В админке выбираем из левого меню Настройки -> WP Tuner.

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

Плагин WP Tuner

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

Но посмотреть число запросов к базе данных можно и не прибегая к услугам плагинов. Для этого нужно получить доступ к файлам вашего сайта по FTP и открыть на редактирование, например, файл /wp-content/themes/название_вашей_темы_оформления/footer.php и где-нибудь в код этого файла нужно вставить следующую конструкцию (место вставки будет определять место вывода количества запросов в футере или по другому — подвале вашего блога):

1 <?php if (is_user_logged_in()) { ?>
2 <?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.
3 <?php } ?>

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

Как уменьшить нагрузку, создаваемую поисковыми ботами, можно почитать здесь http://n-wp.ru/2074.

Об оптимизации шаблонов для снижения числа запросов к БД мы поговорим в отдельной статье.

[Посещений: 1 628, из них сегодня: 1]