Здраствуйте! Это Санёк – автор блога Все о SEO и мой гостевой пост про разгон популярного блогового движка WordPress. Практически все блоггеры используют WordPress и всем известно, что с каждой новой версией движка его аппетит растет. После каждого обновления нужно все больше и больше оперативной памяти. Если ваш блог не очень популярен и на вашем аккаунте на хостинге один или несколько сайтов на wordpress, то можно особенно не беспокоится. Но если вы делаете сателлиты на WP и держите их у одного хостера или у вас большая посещаемость, то рано или поздно у вас возникнут проблемы из-за высокой нагрузки на сервер и медленной загрузки страниц.
Настройку wordpress можно разделить на серверную и клиентскую. Так как свой сервер есть далеко не у всех и его настройка требует навыков администрирования, то речь сегодня пойдет о клиентской настройке движка.
Первым делом установите плагин WP-Tuner, который входит в стандартную сборку от Лекактуса. Этот плагин поможет найти узкие места в вашем блоге. Он показывает количество запросов к базе данных, скорость загрузки страницы, потребление памяти. Если вы обнаружили узкие места (в статистике плагина они помечены желтым), то попробуйте устранить проблему отключением ненужных плагинов. Многие плагины написаны для ленивых, то есть они делают то, что вы в состоянии сделать сами, но вам влом править код)) К тому же некоторые плагины могут иметь свои уязвимости. Следовательно, меньше плагинов – выше безопасность блога
Как правило основное узкое место любого блога – это база данных. Если у вас включены ревизии записей (автоматически сохраняемые черновики) и много спам-каментов, то ваша база данных наверняка имеет приличные размеры. Чтобы оптимизировать БД рекомендую установить плагин WP-Optimize. Данный плагин позволяет удалять спамерские каменты, ревизии записей, оптимизирует таблицы БД, меняет имя администратора. После оптимизации базы данных вы почуствуете значительное ускорение работы блога. Следующий этап – кэширование. Для решения этой задачи лучше всего подойдет плагин WP-Super-Cache. Он имеет множество настроек, но разобраться в них довольно просто. Для паранойков можно подправить шаблон. Дело в том, что многие строчки кода шаблона генерируются php-скриптами. Следовательно можно прописать обычный html код вместо кода вызова php скрипта. К таким строчкам относятся название блога, кодировка страницы, метатэг с версией движка (лучше его вообще убрать), урл главной страницы, путь к css и некоторые другие. Вся эта информация меняется крайне редко и потому можно прописать статический html код.
Чтобы иметь возможность все время отслеживать скорость загрузки блога и нагрузку на сервер, пропишите в подвале следующий код:
<*php
$user = wp_get_current_user();
if ( $user->id == 1 ) {
echo ” MySQL: ” . get_num_queries() . ” запросов за “; timer_stop(1);
echo ” секунд. Потребление памяти: “. round(memory_get_usage()/1024/1024, 2) . ” MB “;
var_dump($GLOBALS['wpdb']->queries);
}
*>В начале и конце кода вместо * поставьте ?
Выводимая информация будет видна только админу, то есть вам. Все эти нехитрые действия позволили сократить на моем блоге количество запросов к БД с 42 до 34, время загрузки страницы с 10 сек до 4 сек и уменьшить расход оперативной памяти на 4 Mb.


27 комментариев к теме
“Разгоняем WordPress”
20 июля, 2009 года
пишет
Я как-то себе пытался поставить Супер Кэш, но вылез какой-то косяк в .htaccess и все [абсолютно все] неожиданным образом похерилось.
И ваще я пост пишу, как ни странно
Ответить
июля 20, 2009 в 21:23
Санёк отвечает:
Тоже было такое)) Чтобы этого избежать, нужно просто прописать mod_rewrite в .htaccess и больше не поддаваться ни на какие провокации) Правда в моем случае просто вместо статей выдавалось 404.
Ответить
июля 20, 2009 в 21:43
Темыч отвечает:
Окей, будем знач еще пробовать.
В футер, кстать, глянь у себя еще [сам не знаю, как я до него добрался] – там портак какой-то с этим плагином.
Ответить
июля 20, 2009 в 22:44
Санёк отвечает:
А у меня ничего не показывает…
Ответить
июля 20, 2009 в 22:54
Темыч отвечает:
Странно, но у меня сейчас тоже ничего не показывает.
Оно и к лучшему
Ответить
20 июля, 2009 года
пишет
Отличная статья, спасибо! Где-то была статья про замену пшп-кода на штмл… найти не могу(((
Ответить
20 июля, 2009 года
пишет
А зачем убирать мета-тег с версией WP?
Ответить
июля 20, 2009 в 22:43
Санёк отвечает:
Это для безопасности. Зная версию движка взломщику проще подобрать “отмычку”.
Ответить
22 июля, 2009 года
пишет
У меня посли этаво вобще никаких изменений, чо эт можэт значить?
Ответить
июля 22, 2009 в 12:58
Санёк отвечает:
Сложно сказать не видя блога. Может он у вас изначально работал достаточно быстро, может тормозит из-за хостера или изменений внесли по минимуму (например не отключили плагины, которые могут нагружать движок).
Ответить
22 июля, 2009 года
пишет
Оо мне помогло!
Теперь грузится чуть больше 2 сек.
Ответить
июля 22, 2009 в 12:55
Санёк отвечает:
Рад помочь) А сколько было?
Ответить
22 июля, 2009 года
пишет
Точно не помню, но навскидку секунд 5.
Ответить
24 июля, 2009 года
пишет
Этот код нужно вписать в код шаблона. Я например поместил его в подвал (footer.php), где он не мешает.
Ответить
9 Окт, 2009 года
пишет
А вы Доктора Хауса смотрите? Там похожие выражения я слышал =))
Ответить
10 Ноя, 2009 года
пишет
Ворд пресс уязвим братья
)
Ответить
ноября 10, 2009 в 17:45
Санёк отвечает:
Нет неуязвимой CMS
Ответить
13 Ноя, 2009 года
пишет
Вся проблема в том, что на wordpress нету кеша.
Ответить
14 мая, 2010 года
пишет
А чем именно вы засекаете время загрузки? У меня wp-tuner показывает 0,7 секунд и я считаю, что это очень много, внешние онлайн-таймеры показывают 1,12 сек… а вы пишите про 5-10 секунд и радуетесь 2 сек…
Ответить
мая 14, 2010 в 22:30
Санёк отвечает:
В статье я привел кусок кода, который выводит время генерации страницы.
На счет 0,7 секунд вы что-то путаете.
Ответить
мая 14, 2010 в 23:00
Алексей отвечает:
Не думаю, что напутал…
Код работает как-то криво, но вот его показатели:
MySQL:193запросов за 0.876секунд. Потребление памяти:34.2 MB
WP Tuner
Analysed in 0.034 seconds.
Render Time: 0.611 cpu sec (81% load, 0.031 startup). Clock: 0.749 sec (20.2% for queries). DB queries: 193, none defective, none > 0.500 sec. Memory: 34.6MB
SuperCash: Dynamic page generated in 0.772 seconds.
Ответить
15 мая, 2010 года
пишет
Мне кажется разница в десятую секунды не существенна. Единственная ваша проблема – большое количество запросов и потребление оперативки, но судя по времени генерации страницы, для вашего хостинга это не проблема.
Ответить
мая 15, 2010 в 17:13
Алексей отвечает:
Cервер часто падает, при посещаемости более 5200, хостер говорит, что не справляется с тяжестью скриптов и заканчивается своп…
Ответить