Оценка производительности разной структуры постоянных ссылок в WordPress

На этой неделе я застрял над следующей проблемой – мне нужно было изменить структуру постоянных ссылок сайта. Первоначально мы использовали формат «День и название» — к примеру, «/2014/11/16/some-cool-post». Нам нужно было немного сократить дату, или хотя бы ее часть. К сожалению, я не был в курсе производительности разных структур постоянных ссылок в WordPress.

Поэтому я решил спросить в Twitter’е.

Но, к несчастью, никто не помог мне. Поэтому я решил провести несколько тестов.

Методология

В WordPress все преобразование, начиная от URL и заканчивая параметрами WP_Query, происходит в методе parse_request() глобального объекта wp.

Этот метод использует хук в самом начале выполнения (чтобы определить, следует ли анализировать запрос) и в конце (чтобы вызвать обработчики действия, когда запрос проанализирован). Я решил просто создать таймер в самом начале выполнения функции и проверить значение этого таймера по текущему системному времени, когда функция завершила свое выполнение.

Чтобы добиться высокой точности, я решил использовать PHP-функцию microtime(), таким образом, мы смогли вести расчеты в микросекундах.

<?php

$query_timer = 0;

add_filter( 'do_parse_request', function( $parse ) {
	global $query_timer;

	$query_timer = microtime( true );

	return $parse;
} );

add_action( 'parse_request', function() {
	global $query_timer;

	$time = microtime( true ) - $query_timer;

	add_action( 'wp_head', function() use ( $time ) {
		echo '<!-- timer: ' . $time . ' -->';
	} );
} );

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

Результаты

На первый взгляд кажется, что вариант «Название записи» (Post Name) является самым быстрым. Средние значения для 10 загрузок отдельной статьи в разных структурах постоянных ссылок были следующими:

• Значение по умолчанию: 1.326ms
• День и название: 2.016ms
• Месяц и название: 1.784ms
• Числовой: 2.194ms
• Название записи: 0.994ms

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

Сказанное выше также приводит к некоторым вопросам: в основном, почему такая статистика не приводится очень часто?

Мы так обеспокоены производительностью, что старательно переносим скрипты и стили в CDN, устанавливаем реверсное кэширование прокси, переносим PHP-приложения на HHVM. Почему мы не заинтересованы в отслеживании времени, которое занимает выполнение базовой функциональности? Ведь мы можем это время оптимизировать!

Небольшое обновление

Коллега задал мне вопрос, влияет или нет массивная база данных на производительность запросов. Я могу сказать наверняка, что раздутая база данных приведет к чуть более медленным запросам. К счастью, метод parse_request() зависит прежде всего от RegEx, таким образом, влияние размеров базы данных сведено к минимуму.

Однако я действительно решил провести тесты повторно на своем очень крупном сетевом сайте, который я перенес на свою локальную машину. Следует учитывать, что базовые тесты я проводил на чистой сборке WordPress без плагинов и со стандартной темой. Мой второй раунд тестов проводился по той же самой методологии, что и первый, однако на сей раз я использовал рабочую сборку с 30+ плагинами и сильно измененной темой, которая была создана для запуска на WordPress.com VIP.

• Значение по умолчанию: 1.882ms
• День и название: 6.002ms
• Месяц и название: 4.418ms
• Числовой: 4.263ms
• Название записи: 6.065ms

Следует учитывать, что эта тема имеет несколько произвольных перезаписей, поэтому все и работает медленнее. Однако в контексте сравнения производительности форматов «День и название» и «Название записи» мы видим, что особой разницы нет.