Сегодня я запускаю тест по моей базе данных, чтобы изучить разницу в скорости доступа к ключу из опций, пользовательских таблиц и переходных процессов. Я запустил тест 1000 раз, и вот время, необходимое для выполнения 1000 операций get:
get_transient()0,0245 секундget_option()0,0068 секунды- операция простого выбора из пользовательской таблицы 0,65 секунды
Я также проверил, что переходный процесс не истек во время этого теста. Итак, вопрос в том, get_option()быстрее get_transient()или я что-то испортил в своем тесте? Настраивается ли задержка пользовательской таблицы из-за того, что WordPress кэширует параметры по умолчанию? Кроме того, параметры также кэшируются различными плагинами кэширования, такими как переходные процессы?
plugin-development
cache
transient
options
learning_13
источник
источник
Ответы:
Имейте в виду, что таблица параметров используется как для параметров, так и для переходных процессов в большинстве систем, и эта таблица была оптимизирована с добавлением индексов. Так что это не честное сравнение
Это также несправедливое сравнение, параметры с установленным
autoloadпараметром будут загружены в расширенный в одном запросе в начале. Такget_optionчто тянетWP_Cache, вариант уже найден.TLDR: На самом деле выборка не производится, она уже получена, она просто извлекается из памяти благодаря
autoloadопцииЭто не должно влиять на нормальную систему при переходном извлечении, ведь он не знает, истек ли он, пока не будет извлечен.
Это зависит:
get_optionвызовautoloadустановленным на true все загружаются в один вызов в начале, поэтому они хранятся в памяти, после этого запросы не выполняютсяОчень возможно, но скорость выполнения выбора во многом зависит от запроса и дизайна таблицы
Да,
WP_Cacheиспользуется, который будет хранить его в памяти для остальной части запроса. Плагины для кэширования могут сохранять эти значения по соображениям производительности.стабильность
Все они кэшируются через,
WP_Cacheпоэтому при втором запросе БД не задействована.Изменчивость и она зависит
Все это предполагает общую основу, но как насчет объектных кешей?
Давайте представим экземпляр MemcacheD или экземпляр Redis (я НАСТОЯТЕЛЬНО рекомендую вам сделать это, если у вас есть возможность, ОГРОМНОЕ повышение производительности для хорошо построенных сайтов, особенно если вы используете их для кэширования страниц, если у вас нет чего-то вроде настройки Varnish)
Теперь у нас новая ситуация:
WP_Cacheтом, что обычно нет. Например,WP_Postобъекты, мета и т. Д.WP_Cacheтеперь сохраняется через запросыТеперь переходные процессы и параметры имеют одинаковую стоимость доступа. Они уже были близки, но теперь они ничтожны и больше связаны с нагрузкой на процессор во время запроса.
Так что для производительности я должен использовать переходные процессы или параметры?
Хотя вопрос стоит задаться вопросом, ответ таков: разница незначительна и находится в пределах погрешности
Так что прекратите микрооптимизацию, это один и тот же носитель, а это не стоит вашего времени
Не стоит тратить время на то, чтобы выбрать один из двух в зависимости от производительности, в этом нет существенной разницы.
Есть намного лучшие вещи для оптимизации, которые дают значительно большую экономию, например, использование таксономий вместо мета в пост-запросах, не использование
__notпараметров стиля, выполнение меньшего количества операций на странице, установка кеша объектов, уменьшение количества постов на странице, избегание удаленных запросов. так далееА как насчет таблицы, которая будет ...
Нет, таблица параметров уже хорошо оптимизирована, использование пользовательской таблицы просто переместит операции за пределы системы WP Caching, заставив вас написать свою собственную.
источник
Если объектное кэширование не найдено, он
get_transientвызываетget_optionдва раза, один раз или интервал истечения и один для значения, поэтому он не будет быстрее.get_optionПроизводительность сама по себе будет зависеть от того, является ли параметр «автозагрузкой» (по умолчанию) или нет. Все параметры автозагрузки извлекаются в одном запросе к БД и сохраняются в кеше памяти, поэтому их количество не должно сильно влиять на количество вызовов,get_optionдаже если это разные параметры.Когда вы обращаетесь к БД напрямую, вы пропускаете все улучшения кэширования и другие улучшения производительности, и ожидается, что это будет медленнее, если вы сами не реализуете какую-то умную логику.
Несмотря на все сказанное, я не уверен, что ваш тест был хорошим, но, тем не менее, все обсуждение бессмысленно, так как если вы действительно заботитесь о производительности, вы будете использовать систему кеширования объектов (и соответствующий плагин), которая значительно уменьшит время доступа к данным. нулю .... и, конечно, если вы решите использовать свои собственные таблицы БД, вам следует интегрировать свои API доступа с механизмом кэширования объектов.
источник