Сегодня я хочу поговорить о том, как снизить нагрузку на сервер хостера, создаваемую вашим блогом на 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-атаки и работа поисковых роботов. С учетом того, что они могут открывать помногу страниц подряд или вообще одновременно, а банить их нельзя, ибо куда же без них, то могут опять же возникнуть проблемы с хостером.
Основные причины перегрузок
Основные причины, по которым блог очень сильно нагружает хостинг:
- Вывод последних комментариев (обычно ставят на отображение 10 последних – а это дополнительные 10 запросов к БД)
- Вывод последних новостей в специальном блоке (нет смысла в этом блоке, если на главной странице почти у всех и отображаются 5-10 последних новостей)
- Вывод самых комментируемых новостей (опять же лишние запросы…)
- Большое количество совсем не нужных установленных виджетов.
- Много опять же не нужных установленных плагинов.
- Множественные лишние запросы в самом шаблоне, которые можно заменить на статическое содержимое.
Методы борьбы с нагрузкой
Для начала, нужно выяснить, что случилось недавно. Возможно, у сайта резко выросла популярность. Возможно, сайт был недавно обновлен (установлена свежая версия 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 для отображения времени загрузки блога, количества обращений к базе данных и объема потребляемой оперативной памяти.
Если простым кэшированием не обошлось – нужен взгляд профессионала. Необходимо найти “плохой” плагин или модуль, и обновить, починить или заменить его. Навскидку – могу порекомендовать отключить модули статистики и использовать вместо них счетчик LiveInternet или Google Analytics. Полная оптимизация сайта может занять огромное количество времени (и денег), так что устраняйте проблемы по мере их возникновения :)
Блокировка запросов на новые версии
Движок WordPress устроен таким образом, что при каждом входе в административную часть он смотрит, не обновился ли какой-нибудь плагин. Как он это делает? В каждом плагине прописана его страница, обычно это раздел в каталоге плагинов на сайте wordpress.org. Заходя туда, он сравнивает версию, установленную в у вас с той, что находится на сайте плагина. Если там более новая, то он предлагает обновить плагин.
То же самое он делает и по отношению к самому себе – каждый раз проверяет, не сделали ли разработчики WordPress новую версию. Понятно, что такая работа отъедает у вашего сайта и так те немногие мегабайты памяти, которые выделяются провайдером на его функционирование.
Я не привык часто обновлять плагины, и, один раз подобрав их и настроив, предпочитаю больше с ними не возиться, исповедуя принцип “работает – не трогай!”. Поэтому мне достаточно три-четыре раза в год проверять, не вышла ли новая версия какого-нибудь, плагина, а на остальное время отключать эту функцию.
Раньше я делал это руками, исправляя конфигурационный файл. Так продолжалось, пока Калинин Иван не сделал плагин, который на лету лишает WordPress проверки на обновление плагинов. Заодно он отключает и сам WordPress от проверки на обновления. Называется этот плагин Блокировка запросов на новые версии. Работает плагин просто: активировали – работает, не активировали – не работает.
Автоматическое управление версиями (ревизиями)
После того, как вы отредактируете какой-нибудь пост, WordPress сохранит предыдущий вариант, чтобы в случае чего можно было сделать откат. Но вот незадача – это “в случае чего” у меня случается крайне редко, и по сути все эти дубли предыдущих версий моего поста мне не нужны. WordPress делает такие бэкапы периодически, и они все накапливаются и накапливаются. Тратится место для них, а движок находится в состоянии постоянного контроля и бэкапа. Думаю, что мне это не нужно, поэтому я отключаю такую возможность (не спорю, для кого-то может и полезную), а заодно экономлю место на сервере и снижаю нагрузку на движок за счет уменьшения базы данных.
Как и в случае с проверкой на обновления, раньше я делал это вручную, исправляя файлы в текстовом редакторе, но этому пришел конец, когда я нашел плагин, делающий все это автоматически: Управление версиями.
После установки плагин покажет, у каких постов есть версии. Думаю, что они вам давно уже не нужны, можете удалять их. После этого неплохо бы указать, стоит ли вам вообще делать такие ревизии постов, и если и стоит, то с какой периодичностью, и в каком количестве. Я вообще убрал все.
Этот плагин, как я уже и говорил, позволяет не захламлять базу данных излишней информацией, а чем меньше база данных – тем быстрее работает WordPress.
Оба плагина хороши прежде всего тем, что не надо лезть в код и редактировать его вручную. К тому же, деактивация плагинов приводит к восстановлению настроек по умолчанию. Это не единственные варианты ускорения работы WordPress, но они – самые доступные.
Плагин WP-Optimize
Вы знаете, что при удалении спамерских сообщений, они не удаляются из базы данных, а просто скрываются с глаз долой? Не знаю, для чего так придумали разработчики WordPress, но лично мне эта коллекция невидимых какашек точно не нужна. Хотя я ее и не вижу, но место она в базе данных занимает. А вам нужны ревизии постов?
Я думаю, что после того, как пост опубликован, его промежуточные версии не нужны никому. Разработчики WordPress и на этот случай имеют свое, отличное от других, мнение — все ревизии хранятся в базе данных. Не знаю, нужны ли они другим, но я за все свое время знакомства с WordPress, ни разу не воспользовался ревизиями. Чтобы избавиться от всего этого ненужного балласта, можно воспользоваться плагином 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. На рисунке, приведенном ниже показано, где можно увидеть число запросов к базе данных, которое было произведено при загрузке этой страницы.
Обычные посетители сайта, естественно, этого безобразия видеть не будут, только администратор блога, т.е. вы.
Но посмотреть число запросов к базе данных можно и не прибегая к услугам плагинов. Для этого нужно получить доступ к файлам вашего сайта по 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.
Об оптимизации шаблонов для снижения числа запросов к БД мы поговорим в отдельной статье.