Почему не стоит отключать ревизии 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. Вот что гарантированно добавит производительности вашему сайту — так это нормальный хостинг.

Запись опубликована в рубрике Web-мастеринг с метками . Короткая ссылка для добавления в закладки: Почему не стоит отключать ревизии WordPress.

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

Максим:

Кстати я уже сталкивался с тем, что у меня было много мусора в БД, т.е ревизий постов :) У меня помнится бэкап весил хоть не так много, где то около 2 мб но тем не менее, когда почистил стала всего 200 кб, что намного упростило загрузку главной страницы моего блога, а чистил базу данных от ревизий статей с помощью запроса прямо в phpMyAdmin :)

Павлуха:

Максим, что значит «упростило»? Понимаю — ускорило, но упростило — это что-то новое для меня. Представляю, как приходит посетитель на главную, закатывает рукава и начинает с великим трудом загружать главную из неоптимизированной БД. :) И намного — это насколько? Давай конкретней, в миллисекундах! ;) И чем замерял?

Максим:

Ок) Да, ты прав, в моем случае ускорилась загрузка главной страницы моего блога.

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

Один из сайтов проверки загрузки страницы mainspy.ru

А если через командную строку то вводил обычно ping адрес сайта.ru и смотрел сколько миллисекунд уходило на загрузку :) как то так в общем, есть другой вариант?

Павлуха:

При команде ping сервер вообще не генерирует страницу (не задействует БД). С помощью её можно только проверить, работает ли сервер. Или, по словам Википедии: «косвенно определить загруженность на каналах передачи данных и промежуточных устройствах».

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

Чуть ближе к тому, что нам нужно — сервис www.host-tracker.com. Он показывает время ответа страницы в виде (dns, head, data) total. Т.е. отдельно время DNS-запроса, HEAD-запроса (время генерации страницы — примерно то, что нам нужно), время получения данных и общее время. Конечно, данные зависят от точки мониторинга. Например, для моего сайта точка «Kwun Tong, Hong Kong» сообщает такие данные: (420 ms, 658 ms, 1632 ms) 2710 ms, тогда как точка «Zurich, Switzerland» в то же время показывает вот такой результат: (94 ms, 31 ms, 37 ms) 162 ms. Совершенно сложно судить о ситуации при таком разбросе.

Более точный результат показывает PHP-код: echo 'MySQL: ', get_num_queries(), ' запросов за ', timer_stop(0), ' сек.' — добавленный, например, в файл footer.php темы оформления блога. Он позволит увидеть данные по времени генерации страницы, полученные непосредственно от сервера, без всяких задержек в каналах передачи данных.

Но мы так и не выяснили, на сколько конкретно секунд уменьшилось время генерации твоей главной страницы. И, подозреваю, вряд ли уже выясним. ;)

Максим:

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

Павлуха:

Точно. Ну, успехов. ;)

Добавить комментарий для Максим Отменить ответ

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