MaxSite.org
Всё о создании веб-сайтов

О нагрузке WordPress-сайтов

PHP

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

Как правило, первое, что делает блогер - это устанавливает кэширующие плагины. Нагрузка, если и уменьшается, то незначительно. Далее, начитавшись «якобы гуру», начинают самостоятельно «оптимизировать» шаблон или даже сам WordPress. Тут можно только посочувствовать, особенно умиляют советы о включении например gzip-сжатия в самом шаблоне. Стоит ли говорить, что подобные действия в самом лучшем случае не приводят к результату вовсе, либо, наоборот нагрузка на сервер ещё больше увеличиватся.

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

MaxCache и другие кэши

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

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

«Кэширование» в .htaccess

Некоторые плагины для «ускорения» WordPress меняют файл .htaccess, прописывая в нем инструкции для принудительного кэширования файлов для браузеров на длительное время. Технически браузер не загружает файл с сервера сразу, а вначале проверяет его наличие в своём кэше (на компьютере). Для этого он посылает короткий запрос серверу и сервер может возвратить ответ «Файл не изменился». То есть браузер уже не тянет его с сервера, а берёт из своего кэша. Понятно, что скорость загрузки страницы в этом случае возрастает многократно.

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

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

Сжатие с помощью gzip

Другой частой ошибкой является включение gzip-сжатия. Само по себе сжатие позволяет сократить трафик примерно на 30%, но только для текстовых файлов. Как правило файлы изображений плохо сжимаются и выигрыш будет очень маленький.

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

Само сжатие должно быть включено на уровне сервера. Обычно эту инструкци прописывают в .htaccess.

Не путаем трафик и нагрузку на сервер!

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

Нагрузка на сервере характеризуется несколькими основными показателями. В первую очередь - это загрузка процессора (CPU). Обычно измеряется от 0 до 100% (или от 0 до 1). 100% - это значит, что процессор полностью загружен в заданный промежуток времени, например за 1 минуту.

Хостеры как правило учитывают этот показатель и закладывают лимиты в тарифные планы. Например для дешёвых тарифов CPU может ограничиваться 2-3%, а дорогих 10%. При этом предполагается учёт пиков: например в течение 30 секунд сайт может потреблять 70% CPU.

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

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

Нагрузка в виде «процессорного времени»

Когда-то давно хостеры использовали только ограничение на трафик. То есть нужно было платить только за объем скачанной информации. После, сделали трафик безлимитным (точнее очень большим), но ввели ограничение на использование CPU. То есть те же самые сайты, которые раньше спокойно работали на сервере, вдруг стали не укладываться в отведенные лимиты CPU.

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

Плохая новость для WordPress-блогеров в том, что, как правило выделенных процессорных минут (обычно 100 минут) хватит примерно для 2 тысяч хостов в сутки. Если посещаемость превышает 2000 посетителей, то для сайта на WordPress превышение процессорного времени будет 10-100% (110-200). То есть хостер вышлет уведомление с просьбой уменьшить нагрузку либо перейти на более высокий тариф.

Потребляемая php-память и MySQL

Давно известно, что WordPress-разработчики давно «забили» на оптимизацию своего «движка». Вместо этого тупо увеличили минимальные требования к серверу. Именно поэтому WordPress требует для работы как минимум 32Мб памяти, а для админки 256МБ.

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

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

Что касается MySQL - запросов к базе данных, то тут более сложная ситуация. Запросы бывают разные. Существую короткие, но затратные по ресурсам sql-запросы, а бывают длинные, но быстрые. То есть в целом, если хостер жалуется на превышение лимитов MySQL, следует провести анализ запросов и выявить медленные. Это задачка для опытного вебмастера, а для рядового блогера решается путем отключения плагинов и/или смены шаблона. Но, в любом случае, использование базы данных достаточно затратно для сервера, поэтому всегда следует стремиться к уменьшению количества запросов MySQL.

Чтобы получить статистику своего сайта добавьте в подвал (как правило файл footer.php) сайта следующий код:

<?php
    echo '<div style="text-align: center">WordPress: '
        . round(memory_get_usage()/1024/1024, 2) . 'MB '
        .' |  MySQL:' . get_num_queries() . ' | ';
    timer_stop(1);
    echo 'sec</div>';
?>

Этот код выводит потребление памяти, количеств запросов к MySQL и общее время, которое потратил сервер на формирование страницы.

Память должна быть где-то до 15-20МБ (мы говоим о WordPress! Для нормальных сайтов - не более 8-10Мб). Запросов - до 30-40, если их более 100, то не откладывайте вопросы оптимизации. Время будет зависеть от мощности сервера, но обычно приемлемо менее 1 секунды. Причем обязательно нужно снять время несколько раз, просто обновляя страницу (F5): на время может влиять объем трафика страницы и используемого кэша. Я бы рискнул назвать «пограничным» значением - 0,5 секунд. Если время больше, значит нужно подумывать об оптимизации, если более 1 секунды - то тут уже без вариантов.

Трафик

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

Самый простой вариант быстро проверить объем трафика - воспользоваться «Информация о странице» в FireFox.

Думаю, что нормальный размер страницы - менее 50Кб. Если размер больше, то стоит подумать об оптимизации.

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

Следующий источник трафика - js-скрипты и css-файлы. Можно воспользоваться «Веб-консолью», но удобней воспользоваться расширением HttpFox. HttpFox выдаёт http-заголовки, размер, все адреса и прочую информацию, глядя на которую можно оценить затраты на трафик и время загрузки каждого файла.

Обратите внимание на 304-заголовок - это ответ сервера, что файл не изменился и браузер его возьмет из своего кэша.

Очень часто в WordPress'е загружают несколько копий jQuery. Каждая из них весит примерно по 100Кб, так что есть смысл проанализировать кто «безобразничает» и наказать «сорванца». :-)

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

Общие рекомендации

Понятно, что основная проблема WordPress'а - это сам WordPress. Точнее наплевательское отношение к оптимизации кода начиная от самих разработчиков, до плагино/шаблоно писателей и самих блогеров. Данный факт в WordPress'е доведен до абсурда. В wp-config.php вы можете ради интереса временно включить режим отладки (точнее отображение ошибок):

define('WP_DEBUG', true);

Впрочем, ситуацию всё равно не изменить, но можно попытаться хоть как-то минимизировать.

На сервере:

  • Проверьте логи php-ошибок на сервере. Если есть какие-то ошибки, то их следует исправить. В любом случае ошибки должны исправляться, а не скрываться.
  • Если есть возможность, попробуйте на сервере включить eAccelerator и PHP как fastCGI. Это позволит немного оптимизировать работу PHP и уменьшит расход памяти.
  • Если позволяют финансы, то лучше перейти на VDS (виртуальный выделенный сервер). Здесь уже все ресурсы будут своими и никто не укажет на превышение нагрузки. Правда следует учитывать, что как правило VDS слабее обычного виртуального хостинга и скорость работы сайта уменьшится. Думаю, что нет смысла брать VDS с CPU менее 2ГГц и памятью менее 1Гб.
  • Учитывайте, что нагрузка на сервере считается по всему аккаунту. Если у вас несколько сайтов, то следует оптимизировать каждый из них.

В самом WordPress:

  • Отключите все неиспользуемые плагины. Любой активированный плагин, даже если он не используется, всё равно требует каких-то ресурсов. Такие плагины следует включать только перед использованием. Это касается всяких бэкапов, статистики и т.п.
  • Отключите «спорные» плагины, вроде запрета копирования. Это глупость, которая обходится любым пятиклассником. Вообще, все плагины, без которых ваш сайт может обойтись, следует отключить.
  • Поменьше работайте в админ-панели. Админ-панель очень прожорлива в создает большую нагрузку, особенно на страницах загрузок файлов.
  • Используйте приведенный мной код статистики потребления ресурсов. Чтобы статистика не была видна на сайте, её можно расположить в html-комментарии.
  • Количество говнокода в плагинах WordPress - просто поражает! Такое впечатление, что у плагинописателей одна цель - нанести как можно больший вред сайту. Поэтому по возможности проверяйте каждый используемый плагин на нагрузку. Возможно есть аналог, написанный не так похабно.
  • Если сайт потребляет слишком много ресурсов, возможно дело в шаблоне. WordPress-шаблоны, к сожалению, часто делаются слишком ресурсоемкими, поскольку разработчики WordPress полностью сосредоточены на красотах админ-панели и не предлагают вебмастерам удобных и эффективных решений. Поэтому они вынуждены придумывать код, который часто не всегда хорош.

Радикально:

  • Используйте MaxCache. Он тоже является «костылём», но если другие варианты не помогают, то кэш позволит хоть как-то привести WordPress в чувства. При этом очень осторожно используйте другие кэши. Обязательно отслеживайте показатели статистики до и после. Доверяйте не красивым текстам, а реальным цифрам.
  • Смена «движка» на что-то более легковесное, например MaxSite CMS.

Если ничего не помогает:

  • Перейдите на более старую версию WordPress. Я бы посоветовал WordPress 2.3.3, причем моей сборки, поскольку в ней реализован lite-перевод, а также подобрана неплохая коллекция плагинов. Шаблон, да, скорее всего, придется переделывать, но оно того стоит: технически шаблоны WordPress застряли в каменном веке и делаются одинаково с версии 1.5.
  • Отключите русский перевод. Русский перевод сейчас занимает почти 700Кб. И это только сам файл, не считая ресурсов на его загрузку, обработку и вывод. Отключив русский перевод, можно получить довольно существенное ускорение работы сайта.

Ну и на последок. WordPress - очень прожорлив. Поэтому не нужно думать, будто бы эта проблема обойтет вас стороной. При увеличении посещаемости уже до 200 хостов хостер предложит перейти на более высокий тариф. При 2 тысячах - потребуется уже отдельный сервер или переходить на MaxSite CMS. В любом случае всех этих трат можно было бы заранее избежать, если сразу пользоваться нормальными CMS. ;-)

Комментариев: 34 RSS

1Nisadoji22-09-2012 18:43

Как пример, уже очень давно используем MaxCache на новостном сайте kochegarka.com.ua, при посещаемости обычно 1000-1500 посетителей в день, а в отдельные дни и до 4500-5000 посетителей в сутки, проблем с доступностью сайта не возникает, так же отсутствуют претензии со стороны хостера, т.к. укладываемся во все лимиты. При этом на сайте активировано 23 плагина и очень часто редакторы работают с админкой. И всё это на недорогом у нашего хостера - ukraine.com.ua

Короче говоря, очень рекомендую данный плагин :)

2Зучкин22-09-2012 22:36

Я бы не был так яростен по поводу кеширующих плагинов - три сайта на вп с гиперкешем создают почти 10к трафика в сутки и не вызывают гневных писем от хостера на простом шаред тарифе

3MAX22-09-2012 23:56

Трафик - это не нагрузка. Ну и гиперкэш как раз один из тех, кто может привести к увеличению нагрузки.

4MAX23-09-2012 00:17

Вообще, чтобы закрыть тему эффективности кэшей, могу сказать, что единственный кэш, который может сравниться с MaxCache - это WP Super Cache. Между ними разница в том, что WPSC тратит довольно много ресурсов на построение кэша. Мой же гораздо меньше, практически не тратит ресурсов на самообслуживание. Поэтому, нередки ситуации, когда WPSC не просто увеличивает нагрузку, а буквально «валит» сервер («кэш» нужно обязательно построить!). Кроме того, WPSC сложен в настройке, а в режиме «half» проигрывает моему примерно в десятки или даже сотни раз. В режиме «full», если получится его настроить, WPSC перекладывает отдачу кэша на сторону сервера (в виде многочисленных инструкций в .htaccess). Мой же использует «чистый» PHP, хотя и очень быстрый. Любой другой кэш, который работает в рамках WordPress и не использует «перекладывание» отдачи статики на сервер будет гарантированно проигрывать моему многократно. В сто или тысячу раз его показатели будут хуже MaxCache.

5Vladimir Statsenko23-09-2012 12:20

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

Но есть одна проблема, о которой вы не написали. Основная причина популярности WP - наличие огромного количества бесплатных плагинов и тем. Естественно, качество 90% таких расширений очень низкое. Есть даже не единичные примеры когда эти расширения не только увеличивают нагрузку, а и создают "дыры" безопасности. Но фокус в том, что годовая стоимость даже не самого дешевого хостинга обычно меньше чем разработка качественного, уникального шаблона (или плагинов) для какой-нибудь CMS. Если базовых возможностей движка достаточно, то всё отлично, но как только вопрос коснется привлечения программистов, большинство владельцев сайтов начнет считать деньги.

6Алексей23-09-2012 18:11

Спасибо за статью, очень познавательно. Вот мои данные WordPress: 41.34MB | MySQL:113 | 0,376sec Куча плагинов, хостер за 170рублей (известный рашен), 6500 хостов в сутки, в момент проверки 90 человек онлайн, включен плагин wp super cache, пока не просят ничего хостер :D, я даже сам у них спрашивал, мол как нагрузка :D, пишут нормик. Хотелось бы услышать объективный ответ, стоит ли ставить в этом случае MaxСache и насколько снизится нагрузка, ибо скоро там будет 10-15к трафика, думаю остаться на том же хостинге.

7Алексей23-09-2012 18:12

ЗЫ, проверял я с отключенным кешированием.

8MAX23-09-2012 20:13

Значит вам удалось настроить WPSC. Считайте повезло. :)

10Владимир26-09-2012 00:41

- Значит вам удалось настроить WPSC. Считайте повезло.

- MAX, помогите, посоветуйте, как правильно... пожалуйста. Материал о "правильной настройке" WPSC был бы очень полезен многим пользователям WP.

12Алексей28-09-2012 10:51

Максим, а есть ли возможность отключить кэширование страниц Вашим скриптом по маске урла, например для определенной папки, в инструкции я нашел только для конкретного урла?

13MAX28-09-2012 19:18

Да, можно. Любые условия можно задать в index.php путем анализа входящего урла в $_SERVER['REQUEST_URI'].

14Алексей29-09-2012 16:09

А можно подробнее, я в этом чайник, что сделать чтобы папка /go/ которая лежит в корневой директории блога и все урлы которые через неё идут не кешировались.

Ато пришлось пока отключить кэш...

Спасибо заранее за ответ

15MAX29-09-2012 16:38

Вот пример кода:

<?php
$_cache_run = true;
if (isset($_SERVER['REQUEST_URI']) and strpos($_SERVER['REQUEST_URI'], '/go/') !== false)
{
        $_cache_run = false;
}
if ($_cache_run)
{
        require_once('maxsite-cache.php');
        if (maxsite_cache()) return;
}
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
if ($_cache_run) maxsite_cache_end();

Нужно смотреть что отдается в $_SERVER и от этого плясать.

16Roman19-10-2012 11:39

Начинаю плавно переходить на DLE в попу Wordpress.

17MAX04-11-2012 21:10

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

18Виталий04-12-2012 23:31

Max, как сделать обновление кэша в MaxCache, по расписанию? Не через равное количество времени, как сейчас в файле настроек, а например, - в 07:00 и в 16:00?

19MAX04-12-2012 23:33

Наверное только по серверному крону очищать каталог cache.

20Виталий05-12-2012 00:31

Я думал об этом, но не знаю как сделать. Что нужно запустить кроном, чтобы очистить папку cache? Наверное есть простая команда для удаления файлов в директории, но вот какая?

По поводу работы самого скрипта, - очень оправдал ожидания. По сравнению с налаженным WPSC, MaxCache позволил уменьшить нагрузку на сервер примерно вдвое, причем если сравнивать работу вообще без кэширования, то в разы... Теперь мне не нужно переходить на премиум хостинг :)

21MAX05-12-2012 01:32

Я не знаю, туту нужно админов «дёрнуть». В кроне указать соответствующую команду и путь на сервере. Гугл выдаёт вариант:

rm -fr /Полный путь до папки/*

23Анатолий13-12-2012 11:12

Можно ли использовать хоть какой то плагин для подсчета количества просмотров страниц вместе с вашим кэшем?

24MAX13-12-2012 11:17

С кэшем подсчет работает, только статистика обновляется после сброса кэша.

25Анатолий13-12-2012 12:24

Я использую WP-PostViews. Те просмотры когда срабатывает кэш не засчитываются. Может быть Вы посоветуете другой плагин для подсчета просмотров?

26MAX13-12-2012 12:37

Я не занимаюсь WordPress, поэтому помочь не смогу.

27Nisadoji13-12-2012 12:45

Анатолий, попробуйте поставить дополнительно к WP-PostViews ещё и плагин http://wordpress.org/extend/plugins/ajax-the-views/ , правда он на одном из моих проектов работает на версии wordpress 2.8.4, да и сам плагин давно не обновляется.

28Анатолий13-12-2012 14:56

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

Попробовал даже починить ajax-the-views как тут обсуждали http://wordpress.org/support/topic/ajaxize-for-wp-post-views - тоже не вышло. Пробовал с помощью Ajaxize вывести функцию - также не вышло. Наверное это все-таки можно решить, но только если использовать wp-super-cache к примеру.

29Елена23-06-2015 19:59

Здравствуйте!

При посещаемости 2000-2500 посет/сутки, а иногда и до 3500 посетителей доходит.

А если будет на сайте 8000-10000 посет/сутки выдержит?

30MAX23-06-2015 20:54

Если сервер потянет такое количество http-запросов, то кэш выдержит.

31Елена23-06-2015 22:55

у меня в тарифе cpu на сервер максимум 50, сможет снизить?

если что-то не так пишу, прошу прощения

32MAX23-06-2015 23:11

Кэш снизит точно, но насколько сказать сложно. Это и так мизерный лимит. Работа в админке (там где кэш не работает) может уже создать превышение нагрузки.

33Елена24-06-2015 00:45

да, сейчас посмотрела в день загрузки и публикования статей нагрузка достигает 167 !!!

что же делать в таких случаях?

34MAX24-06-2015 11:51

Менять хостинг на нормальный и после этого ставить кэш — это ускорит загрузку сайта посетителям.

Оставьте комментарий!

Комментарий будет опубликован после проверки. Вы соглашаетесь с правилами сайта.

(обязательно)