Как мы с бубном танцевали, или WordPress и его тормозные колодки

Разогнать WordPress до скорости света невозможно, так как при этом его масса возрастет до бесконечности, а за такой хостинг можно и пизды нобеля получить. Но в целом, тормоза этой CMS сказываются на всем, что только попадется в ее ведение. Не сказать, что это Joomla, которая с третьей версии вообще «топорной» стала, но как что серьезное создается на WP — он всюду своими колючками жопу колоть начинает. Неприятно, но в отличие от Joomla — решаемо. Причем без анестезии. Чем мы и занимались.

Перво-наперво полезли в логи хостинга. Само собой — виртуального. Был бы выделенный или (хуясенаглецы) собственный — там бы через Apache и прочие пути проблему решили. Правда, если проблему купировать, а не лечить — можно б было на процессоре яйца жарить.

Логи нам показали, что сервак «кладет» на ломатки cron. Не тот cron, что в настройках хостинга прописывается, а тот, который сам WordPress заводит. По сути, если не используется что-то мега-арбитражное — он не нужен. Т.е., если на WordPress вы не замутили аналог Facebook — первый этап лечится через две строки.

1. В файле wp-config.php добавляем строку:

define(‘DISABLE_WP_CRON’, true);

2. В файле wp-cron.php комментируем строку:

// ignore_user_abort(true);

Собственно, это главная фича, которая у нас все тормозила. Объем данных на проекте был большой, и Cron просто не позволял самим собой должным образом развернуться, что постоянно вызывало ошибку то 500, то 304 (по настроению ;).

Для еще большей шустрости установили плагин WP Super Cache из репозитария WordPress.

Здесь сделаю отступление: есть еще такой зверь, как Hyper Cache. Оба хороши, но WP Super Cache имеет особенность: здесь можно отключить кеширование для зарегистрированных пользователей, редакторов, авторов, админов или вовсе — для некоторых пользователей, кого пожелаете. Это бесконечно удобно, когда проект находится в процессе отладки и необходимость после каждой правки (например, CSS-таблицы) чистить кеш. 

Кроме того нашли отличный плагин от Владимира Колесникова — WP File Cache. Так же можно найти в репозитории, а то, что он реально снижает нагрузку на базу данных MySQL — проверено логами её же, родимой.

Еще несколько плюшек, с которыми поколдовали

Во всех версиях wordpress, начиная с 2.6, редакции ваших статей каждый раз во время правки автоматически сохранялись. Это замедляет работу БД и увеличивает ее размер без особой надобности.

Чтоб отключить post revisions, добавьте строку в wp-config.php:

define('WP_POST_REVISIONS', false);

Чтобы удалить сохраненные ранее ревизии текста, выполните следующий запрос в PHPmyadmin:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Кроме того — поправили файл .htaccess (куда ж без него-то?). В результате уменьшили размер загружаемой страницы, позволив браузеру принимать и передавать данные в сжатом виде. Это также снизит загрузку канала и количество загружаемых данных. Сделали это путем добавления нехитрого хитровытраханного кода:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

Право, здесь стоит отметить, что все зависит от требований и настроек виртуального хостинга. Как было проверено — даже на Denwer при некоторых настройках «апача» этот  метод в .htaccess неминуемо вызывает ошибку 500.

Еще почитать:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *