";?>

echo " WordPress: " Round (memory_get_usage () / 1024 / 1024 , 2 ) . "MB " . " | MySQL:" . get_num_queries () . " | " ; timer_stop (1 ) ; echo "sec " ; ?>

Запросов к MySQL Скорость генерации страницы Без скрипта 11.68 MB 31 0,68 С MaxCache 0.82 MB 0 0,00025

Нагрузка на сервер снизилась более чем в 14 раз!

Количество обращений к базе данных при использовании скрипта нулевое!

Скорость генерации страницы увеличилась в 2720 раз!

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

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

Кеш страниц сбрасывается каждые 4-е часа. При желании можно указать собственные настройки.

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

Имеется возможность включения gzip-сжатие трафика. Увеличивает скорость загрузки «тяжёлых» страниц. Включение gzip-сжатия даёт дополнительную нагрузку на сервер. Включать или нет эту функцию нужно принимать решение исходя из наличия лимитов по нагрузке CPU. Перед включением gzip-сжатия нужно уточнить у хостера поддерживается ли эта функция сервером.

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

Результаты для главной страницы получились следующие.

До сжатия вес моей страницы был 23,7 KB, после компрессии 6,5 KB. Экономия составила 72,4%. Как говорится - Без комментариев. Сервис проверки работы gzip-сжатия находится по этому адресу - http://www.whatsmyip.org/http_compression/ .

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

В завершение статьи, хотелось бы подчеркнуть, что мне нравится подход автора скрипта к его продажам. После оплаты MaxCache покупатель получает Lite -версию скрипта. Эта версия с ограниченным функционалом. Отличается она от Full-версии, тем, что кеш не сбрасывается на автомате. То есть урезанная версия работает, практически так же, как и полная. На тестирование автор выделяет две недели времени. Далее, вы или отказываетесь от приобретения, и автор возвращает вам деньги либо отправляете заявку на получение full-версии MaxCache.

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

Вконтакте

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

Нагрузка на хостинг увеличилась значительно, при количестве хитов положим 500—600 wordpress уже превышал лимиты на использование ресурсов MySQL в три раза, а значит выход стоял либо в кеше (довольно геморном опять же в wordpress), либо в переходе на другой движок.

Я испробовал на локали большинство готовых блоговых движков и пришел к неутешительному выводу:
ни один из них (!) даже при наличии импорта из wordpress, не мог предоставить той же структуры ЧПУ (и уж тем более в автоматическом, интуитивном режиме), а это значит при переходе -> 301 редирект и непонятно какая реакция со стороны ПС в плане существующих позиций.

В итоге получилось как всегда: посмотрел сорцы wordpress, импортнул данные из существующей БД, написал небольшое подобие CMS.

Нагрузка: на MySQL снизилась в среднем в 10 раз, на проц — в 2 раза. Думается мне, что здесь есть еще где развернуться в плане оптимизации, но согласитесь даже это уже показательный результат!

Вывод из данного поста совсем не в том, чтобы всем ринуться срочно писать свои скрипты (подумайте хотя бы о защите от взлома), а в том, чтобы пару раз подумать прежде чем ставить wordpress в качестве блог-движка, ведь потом может быть проблематично сменить ЧПУ и уж тем более адреса существующих ссылок (если они, конечно, не покупные).

15 Комментариев

1. 1

   Мысли хорошие, но они есть у всех. Хотелось бы прочитать вазможное решение проблем с разгрузкой БД изменяя параметры движка

2. 2

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

3. 3

   Всегда в сети говорили, что ВП лёгкий, и я верил, хоть и использую по жизни Drupal. Потом в сентябре у меня появился заказчик, с желанием «Съехать с этого глючного ВП нах на друпал». Оказалось следующее:
   1. Сайт крутился на VPS 500Mhz и 384 рамы
   2. Посещаемость около 1000 хитов в сутки.
   3. Включены все мыслимые и немыслимые кеши.
   Вся эта система стабильно раз в сутки падала, в остальное время безбожно тормозила. Начался суровый и кропотливый процесс переезда на друпал, в итоге:
   1. Все материалы перетянули.
   2. Где урлы устраивали, оставили их, где не устраивали, сделали новые урлы, на старые 301 редирект.
   3. Переехали абсолютно без потерь. С той же функциональностью, а в некоторых местах даже больше.
   Сейчас загрузка сервера по процессору в самые жесткие моменты, когда приходит Гоша и Яша не превышает 30 процентов, с отключенным кешированием.
   Так что, подумайте о друпале, не так он хренов, как все говорят.
   Вот пациент - surlaterre.ru

4. 4

   Ничего против Друпала не имею, хорошая система. Основная моя претензия - в современных движках нет простой системы переезда с другой CMS с сохранением старой системы ЧПУ.

5. 5

   Если взять тот же переезд с ВП, то существующий модуль переносит вместе с ВП-шными урлами, но я переносил своим модулем, у меня несколько иначе было всё

6. 6

   Если тот или другой модуль сумеет перенести любой вид адреса, который можно создать с помощью стандартных средств Wordpress - честь и хвала ему, +1 к друпалу, но когда я искал подобное среди движков ничего не нашел или находил, но реализовано было далеко не все.

7. 7

   В общем могу сказать: «Ничего не переносимого нет», если тема интересна, то велком в аську/почту/скайп. Контакты на моём сайте

8. 8

   Не знаю как у вас был настроен WordPress, сервак и кеши. Но у меня на обслуживании стоят сайты на WP у которых на виртуалках посещалка 4000 в сутки и ни каких проблем. Есть сайты с посещалкой на 10 000 в стуки, но на приватах. Там нагрузка не превышает 10% в пиках. Так что WP рулит еще как!

9. 9

   Я сейчас осваиваю MovableType. Эта CMS несмотря на необычность (используется perl, генерит статические html), очень легкая и достаточно функциональная. Быстрее WP в разы.

10. 10

    MovableType хорош, но информации на русском о нем все же мало.

11. 11

    Я лично вообще не могу разобраться какая там эта нагрузка. У меня крупных проектов WP ни когда не было и проверить я это сам не могу. А где бы я ни почитал, дак ни чего не поймешь одни говорят wp-рулит, другие говорят что фигня движок. А вообще какая все таки нагрузка и и какую wp может выдержать я ни где не встречал. Остается один вопрос почему тогда wp по зоне ru находится на лидирующих позициях?Может из-за своей простоты?

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

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

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

Буквально пару дней назад ко мне обратился один блоггер и инфобизнесмен, которого многие прекрасно знают — Дмитрий Зверев , с просьбой посмотреть сильные подвисания его блога. Естественно я согласен, это ведь моя работа, тем более почему бы не помочь хорошему человеку? 🙂

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

Жесть, не правда ли? Да что тут говорить, помимо такой «скорости», и доступность сайта хромала, порой сайт открывался через раз. Одним словом он катастрофически зависал и отказывался полноценно работать. А самое интересное заключалось в том, что при авторизации в админ-панели проблем становилось ещё больше!

Это вызвало у меня ещё больше интереса, потому что я никогда не ранее не сталкивался с подобным! «Ну что ж, попробуем, чем тяжелее — тем интереснее» — подумал я, и приступил к работе.

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

Таким образом я обнаружил 2 плагина, которые грузили блог значительнее остальных, это LeadPages и NextGEN Gallery. Но после их отключения и очистки кэша абсолютно ничего не изменилось. И тогда началось самое интересное. Я начал копать всё глубже и глубже, дабы выискать истинную причину сего безобразия 🙂

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

И вот, спустя два дня, и множества попыток, в том числе и абсолютно бесполезных, скорость стала следующей:

И помимо этого, прекратились постоянные сбои в работоспособности и хостеры перестали жаловаться на повышенную нагрузку CPU. Ура! К чему стремился, то и получил — миссия выполнена.

Но что именно я делал и как мне удалось одержать победу? Давайте по порядку.

Снижение нагрузки на сервер

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

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

2. Зачастую тормоза появляются из-за скрипта под название WP-Cron . Данный скрипт, встроенный в WordPress отвечает за планирование задач. К примеру, размещение статей по времени, автоматическая чистка корзины, создание резервной копии с помощью плагина и т.д.

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

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

Так вот, для отключения WP-Cron существует несколько способов. Дело в том, что какой-то из них (как было в моем случае) может не заработать, а другой вполне.

1 способ. Переходим в корень Вашего сайта по Ftp, например через FileZilla, и открываете там файл под названием wp-config.php и добавляем новую строчку:

Define(‘DISABLE_WP_CRON’, true);

Желательно добавить её после строки:

Define(‘WPLANG’, ‘ru_RU’);

После чего сохраняете файл и радуетесь, скрипт должен отключиться.

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

2 способ. Опять же, в корне сайта необходимо открыть файл под название wp-cron.php , найти строчку:

Ignore_user_abort(true);

и закомментировать её (отключить) с помощью двух слэшов. На выходе должно получиться вот так:

//ignore_user_abort(true);

Сохраняем файл и cron отключается.

3. Далее, необходимо включить zlib компрессию , которая позволяет значительно ускорить сайт за счет обработки и сжатия php кода. В первую очередь Вам необходимо написать хостеру и узнать включен ли у Вас функция zlib или же нет. Если подключена — отлично, если же нет — просим включить. После чего переходим в файл header.php и в самый самый верх вставляем следующий код:

Сохраняем файл и ощущаем значительный прирост в скорости.

4. После чего очень важно оптимизировать БД с помощью плагина . Переходим в админ-панель, открываем вкладку «Плагины» — «Добавить плагин» и в поиске вбиваем «WP-Optimize», нажимаем Enter и устанавливаем первый плагин.

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

5. Теперь наша задача защитить блог от Ddos-атак , т.к. именно такие атаки зачастую и становятся причиной «сноса мозгов» сайта. Для этого, во-первых, я рекомендую установить плагин под названием iThemes Security, про его настройку я расскажу в следующей статье, а во-вторых, важно использовать блокировку подозрительных посетителей с помощью .htaccess .

Я не буду сейчас объяснять как выискивать таких подозрительных и вредоносных , потому что это тема отдельной статьи, а поделюсь с Вами списком IP-адресов, которые я сумел собрать за некоторое время. Именно их и нужно будет заблокировать.

Давайте наверное уже начнем оптимизировать Поехали!

Пример излишней нагрузки на сервер.

Допустим пользователь зашел на сайт, но что происходит при открытии страницы? Как информация выводится на экран? Давайте проследим сей процесс на примере заголовка сайта.

Заголовок и URL главной страницы сайта, если Вы помните, задается в настройках WordPress: адимнка -> Параметры -> Общие. Все настройки, имеющиеся во вкладке «Параметры», заносятся в базу данных, а точнее, в таблицу wp-options , откуда в последствии они запрашиваются различными функциями и выводятся на экран.

Разработчиками WordPres написано не мало функций, но сами по себе они выполняться не могут. Для полноценной их работы необходимо некое связующее звено, в роли которого выступает шаблон сайта.

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

В большинстве шаблонов, главный заголовок сайта заключен в тег h1 , поэтому ищем участок кода с данным тегом. В моем шаблоне код вывода заголовка выглядел так:

/">

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

С анкором мы разберемся немного позже, а сейчас давайте познакомимся с функцией get_option() .

Функция get_option() и нагрузка на сервер

Итак, мы вписали название и URL главной страницы сайта в настройки WordPress и они отправилось на хранение в БД, в таблицу wp-options .

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

Принцип работы вышеупомянутой функции заключается в обращении к базе данных, а точнее к таблице wp-options и в получении от туда определенных данных, исходя из заданных параметров. После чего, команда echo выводит полученные данные на экран.

Немного сложновато, ну нечего, сейчас я все разъясню. В скобках указывается параметр, в нашем случаи get_option(‘home’) , который сообщает функции, какой тип данных ей надо получить.

Параметр home дает команду функции запросить из БД URL главной страницы. Стоп! Значит URL главной страницы тоже хранится в базе данных? Верно. И при открытии страницы функция его запрашивает, т.е, происходит обращение к данным, которые хранятся на сервере.

А теперь представьте, что на Ваш ресурс зашли 100 посетителей и начали «шалить», открывая все новые и новые страницы.

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

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

Вернемся к функции get_option() . Для получения из БД тех или иных данных, функция может принимать следующие параметры:

get_option("home") — URL главной страницы
get_option("admin_email") — E-mail администратора сайта;
get_option("blogname") — Название сайта;
get_option("blogdescription") — Краткое описание сайта;
get_option("blog_charset") — Кодировка сайта;
get_option("date_format") — Формат даты;
get_option("default_category") — Категория по умолчанию;
get_option("siteurl") — Адрес WordPress (см. Параметры -> Общие);
get_option("start_of_week") — Первый день недели;
get_option("upload_path") — Каталог загрузки по умолчанию (устаревшая);
get_option("posts_per_page") — максимальное число постов на странице;
get_option("posts_per_rss") — Максимальное число постов в RSS-ленте;

Большинство перечисленных типов данных указываются в настройках WordPress, во вкладке «Параметры». Исключением являются: «Кодировка сайта» — указывается непосредственно в БД и «Каталог загрузки по умолчанию «- опция была убрана из настроек с версии 3.5.

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

Как и чем заменить функцию get_option() я расскажу немного позже, а пока давайте выясним, что за bloginfo() прописана в коде вместо анкора.

Функция bloginfo() и нагрузка на сервер

Вернемся к тому моменту, когда пользователь открыл страницу. Мы выяснили, что URL адрес главной страницы был взят из базы данных, средствами функции get_option(‘home’) .

Ну хорошо, а сам заголовок откуда взялся? Заголовок также хранится в базе данных, но в нашем случаи он был получен и выведен на экран другой функцией — bloginfo() .

На заметку! bloginfo() — это тег шаблона, который активирует функцию get_bloginfo() . Может использоваться в любом месте шаблона.

Функция bloginfo() может принимать следующие параметры:

bloginfo("url") — Выводит URL сайта;
bloginfo("name") — Выводит название сайта;
bloginfo("description") — Выводит описание сайта;
bloginfo("template_url") — путь до директории текущей темы;
bloginfo("template_directory") — тоже самое, что и "template_url";
bloginfo("stylesheet_url") — путь до файла стилей текущей темы;
bloginfo("stylesheet_directory") — тоже самое, что и "stylesheet_url";
bloginfo("charset") — Выводит кодировку сайта;
bloginfo("admin_email") — Выводит e-mail адрес администратора;
bloginfo("version") — Выводит версию WordPress;
bloginfo("html_type") — Выводит данные из html_type таблицы wp-options;
bloginfo("pingback_url") — путь до файла xmlrpc.php;
bloginfo("rss2_url") — Выводит URL фида RSS 2.0 (домен/feed);
bloginfo("comments_rss2_url") — Выводит URL фида комментариев (домен/comments/feed);
bloginfo("rdf_url") — Выводит URL фида RDF-RSS 1.0 (домен/feed/rfd);
bloginfo("rss_url") — Выводит URL фида RSS 0.92 (домен/feed/rss);
bloginfo("atom_url") — Выводит URL фида Atom (домен/feed/atom);

Функция bloginfo() немного отличается от функции get_option() , но работает по схожему принципу, т.е, запрашивает из БД те или иные данные и выводит их на экран.

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

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

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

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

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

Технология сокращения запросов к БД

Напомню, как выглядит код заголовка в моем файле header.php:

/">

А теперь, самое интересно. Если заглянуть в исходный код, то код заголовка там примет совершенно другой вид:

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

Но тогда зачем в файлах шаблона прописываются вышеупомянутые функции?

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

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

Поэтому, начиная с файл header.php ищем участки кода, с вышеупомянутыми функциями, затем смотрим, как они выглядят в исходном коде и заменяем.

Для закрепления материала я приведу несколько примеров. Вот код, который выводит информацию о кодировке.

; charset=" />

Смотрим исходный код:

Копируем строчку целиком, и вставляем вместо кода с функциями.

Код подключения файла style.css:

" type="text/css" media="screen" />

Путь до таблицы стилей выведен с помощью функции bloginfo(‘stylesheet_url’) . Смотрим исходный код:

/images/fav.ico" type="image/x-icon" />