Почему не стоит отключать ревизии WordPress

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

Хотя, с точки зрения поисковой оптимизации (теперь уже речь о SEO), разнообразие материала в статье может быть полезно. Потому рядом с описанием плагинов находится место и для чистящих SQL-запросов (их требуется отправлять напрямую в БД через phpMyAdmin). У новичков эти запросы отлично чистят БД — в некоторых случаях после таких чисток хоть новый блог заводи... Почтим минутой молчания всех потенциальных блогеров, которые пошли работать на завод после неудачной оптимизации WordPress.

В любой вышеупомянутой статье рассказывается о том, какое же зло — эти ревизии WP, и как их срочно надо отключать трясущимися от волнения руками! Пока диск на сервере не переполнился и пока всемирным советом хостеров не было решено отказать вашему сайту в услугах хостинга. Причём, ни в одной статье я не видел точных цифр повышения производительности, только какие-то субъективные прозрачные намёки, типа: «мой блог, пожалуй, стал быстрее в 2 раза и получил, наверное, силу Земли». Потому я решил проверить.

Реальный эксперимент оптимизации

Для примерной оценки ущерба, создаваемого ревизиями, я зашёл в админку старого блога, на котором более 1500 постов и более 6000 строк в таблице wp_posts (размер таблицы — почти 23 МБ). Здесь сразу становится ясно, что надо быть очень продуктивным автором весьма длительное время (столько даже не живут), чтобы хоть приблизиться к дисковой квоте на любом нормальном хостинге.

Ладно, иду в плагины и выбираю «добавить новый». Я же не настолько крутой программист, чтобы вручную оптимизировать БД, как советуют в статьях по оптимизации. В поиске нового плагина пишу «clean», и первый в списке найденных — плагин «WP Clean Up». В описании сказано: «removing revision, draft, auto draft...» И многое другое. В общем, то, что надо. Устанавливаю, попутно делая резервную копию БД (вручную — я же крутой программист). После установки «WP Clean Up» мне показывает такую картину:

Дескать, плохи дела блога — 3305 ревизий постов. Но делу ещё можно помочь, если нажать на кнопочку «Delete». Перед тем, как нажать, я ещё делаю замер производительности главной страницы:

MySQL: 47 запросов за 0,293 сек. Память: 36.73MB

Время исполнения варьируется от 0,2 до 0,7 секунды, потому что на сервере работают и другие сайты (причём, некоторые гораздо лучше работают).

Нажимаю заветную кнопочку «Delete», которая обещает сделать мой блог тысячником уже за неделю. Затем жму «Optimize» внизу страницы (без оптимизации таблиц удалённые из них данные продолжают занимать место в БД). Проверяю работоспособность сайтов. Что ж, плагин, по крайней мере, не очистил Интернет от наших сайтов. В БД таблица wp_posts действительно похудела: теперь в ней 2860 строк, и размер её чуть больше 7 МБ (уменьшился в 3 раза). Увеличится ли в 3 раза производительность? Ещё один замер на главной странице:

MySQL: 47 запросов за 0,331 сек. Память: 36.73MB

Скорость выполнения, как я уже говорил, варьируется от 0,2 до 0,7 секунды. Но наибольшая вероятность увидеть его близким к 0,35 с. Так же до и после оптимизации я проверял страницу с большим количеством комментариев. Там страница генерировалась в среднем за 0,5-0,6 секунды. То же самое наблюдаю и теперь.

Результат: в плане производительности не изменилось ничего.

Удаление ревизий — идеальный эксперимент

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

Для чистого эксперимента я взял ту же изначальную таблицу wp_posts, содержащую 6165 строк. Залил в локальную БД на своём компьютере. Из неё вручную удалил все записи со статусом не publish (т.е. удалились черновики и что-то ещё), в результате размер таблицы wp_posts_new стал меньше 7 МБ (1552 строки).

Для замера производительности я выбрал запрос:

mysql_query ( "SELECT * FROM $table LIMIT ". rand ( 0, $c ) .', 1' );

Из таблицы выбирается одна случайная запись. Это смесь PHP и MySQL. Сам запрос выполняется в цикле, и в чётных итерациях $table получает значение wp_posts, $c = 6165. В нечётных $table = wp_posts_new, $c = 1552. Таким образом, даже возможная переменная загруженность компьютера не должна повлиять на результаты эксперимента. Ведь в цикле попеременно измеряется время выполнения запроса к исходной таблице и к оптимизированной.

Цикл запросов выполнялся 10 000 раз (попеременно по 5 000 запросов к каждой таблице). Вот последние строки замеров и суммарный результат:

...
Строк 1552, время 0.0029239654541016
Строк 6165, время 0.010604858398438
Строк 1552, время 0.0059170722961426
Строк 6165, время 0.01646900177002
Строк 1552, время 0.0035150051116943
Строк 6165, время 0.010723829269409
Строк 1552, время 0.0054960250854492
Array
(
[0] => 56.185174942017
[1] => 19.163659334183
)

2.9318604532798

Иными словами, к оптимизированной таблице 5 000 запросов одной (произвольной) записи выполнилось в общей сложности за 19 секунд, а к неоптимизированной — за 56 секунд, что примерно в 3 раза дольше.

Т.е. позитивный эффект от оптимизации всё же есть. Но на то он и сферический конь в вакууме, что в реальной жизни вы такого не встретите и, тем более, не покатаетесь на нём.

Зато отключение ревизий может привести к тому, что вы когда-нибудь нажмёте на кнопку «Опубликовать», а вам в ответ «Неполадки в Интернет-соединении, обновите страницу». Вы обновите страницу, а там пустой новый пост. И то, что вы написали, найти не сможете, потому что ревизии отключены. Со мной такое было, но у меня ревизии работали, и я успешно восстанавливал содержимое поста из ревизии. По мне, так спасённые нервные клетки дорогого стоят.

Вывод

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