Когда дело доходит до создания веб-приложений, одной из самых важных вещей, о которых мы должны постоянно помнить, является производительность.
Как говорится, производительность — это особенность.
И независимо от того, являетесь ли вы дизайнером, разработчиком или пользователем, вы интуитивно знаете, что это правда: когда дело касается приложений, мы ненавидим ждать. Мы расстраиваемся, когда дела идут недостаточно быстро, или нам приходится ждать дольше, чем мы считаем.
С этой целью большинство современных сред веб-разработки позволяют реализовать какой-либо тип кэширования посредством использования определенных API, и WordPress, хотя и является основой, ничем не отличается.
Итак, продолжая обсуждение того, почему WordPress является жизнеспособным вариантом, служащим основой для разработки веб-приложений, мы рассмотрим API-интерфейсы, предоставляемые основным приложением, как они работают, как мы можем использовать их для наше преимущество и то, как можно повысить производительность еще больше с помощью дополнительных плагинов для кэширования.
Почему кэширование важно?
Короче говоря, кэширование важно, потому что оно позволяет нам хранить данные, которые часто извлекаются, в определенном месте в памяти, чтобы их можно было быстро восстановить.
Когда вы смотрите на это в более широком масштабе, это становится все более очевидным, когда несколько пользователей просматривают сайт. Под этим я подразумеваю, что если на сайт заходит один человек или очень небольшое количество людей, а данные сайта хранятся в базе данных, то при каждой загрузке страницы эта информация должна быть получена из базы данных, вставляется в страницу, а затем возвращается к пользователю.
Если установлен уровень кэширования, то вызовы в базу данных не должны выполняться так часто. Вместо этого информация может быть извлечена из области памяти, что приводит к более быстрому извлечению и, таким образом, к более быстрому времени загрузки страницы.
Мы познакомимся с техническими деталями чуть позже в этой статье.
Как насчет плагинов?
Если вы использовали WordPress в течение значительного периода времени, вы, вероятно, знакомы с рядом доступных плагинов для кэширования.
Это, без сомнения, отличное решение для ускорения вашего веб-сайта и / или веб-приложения, но оно поднимает вопрос: если для этого есть плагины, то зачем нам об этом беспокоиться?
Конечно, это верный вопрос, но плагины могут делать столько работы самостоятельно.
Разработчики могут структурировать свои приложения таким образом, чтобы они не только хорошо работали без механизмов кэширования, но также были значительно улучшены указанными плагинами кэширования.
Под этим я подразумеваю, что эти плагины для кэширования ищут данные, которые должны храниться в определенном месте по темам и приложениям, и если мы сможем сделать это программно в контексте нашей собственной работы, то плагины приведут к еще большей производительности.
После того, как мы рассмотрим доступные API, мы вернемся к этой теме, чтобы увидеть, как они повышают производительность плагинов для кэширования, позже в этой статье.
API переходных процессов
Чтобы внедрить наш первый уровень кэширования в приложение, нам нужно воспользоваться API-интерфейсом WordPress Transients . Во-первых, обратите внимание, что официальное определение переходного процесса — это «то, что существует только в течение короткого периода времени».
Как определено в Кодексе:
[Переходный API] предлагает простой и стандартизированный способ временного хранения кэшированных данных в базе данных, назначая ему произвольное имя и временные рамки, после которых они истекают и удаляются.
Но что это значит точно? В конце концов, данные все еще хранятся в базе данных, так почему это лучше, чем хранить данные, хранящиеся в любой другой таблице базы данных (например, в таблице wp_options ?)?
Как только мы вернемся к обсуждению кеширования и плагинов, мы поговорим об этом более подробно.
Установка переходных процессов
Установить временное значение на самом деле очень просто, и это очень похоже на хранение данных в таблице параметров.
В частности, вам нужно значение ключа, которое будет однозначно идентифицировать данные, а затем вам нужно значение, которое будет связано с этим ключом. Вам также нужно время истечения (в секундах), чтобы сохранить данные в таблице перед ее обновлением.
Допустим, мы хотим сохранить имя текущего пользователя в качестве последнего или самого последнего активного пользователя на сайте. Мы можем сделать это, воспользовавшись wp_get_current_user() .
Сначала мы установим значение следующим образом:
set_transient( 'most_recent_user', wp_get_current_user()->user_login, 12 * HOUR_IN_SECONDS )
Здесь обратите внимание на пару вещей:
- Я идентифицирую самого последнего пользователя в системе как текущего пользователя, который вошел в систему, и мы храним его в течение 12 часов.
- Обратите внимание, что константы
HOUR_IN_SECONDS— это то, что было введено в WordPress 3.5. Полный список констант доступен здесь .
Хотя это то, как мы настраиваем переходные процессы, это не учитывает, как мы можем управлять переходными процессами, если они не существуют или если они уже существуют.
Об этом мы поговорим чуть позже в статье.
Извлечение переходных процессов
Когда дело доходит до извлечения переходных процессов, это очень похоже на извлечение таких вещей, как метаданные или параметры. Под этим я подразумеваю, что нам просто нужно знать ключ, по которому можно получить информацию.
Таким образом, в соответствии с приведенным выше примером, мы можем получить самого последнего пользователя приложения с помощью следующего вызова:
get_transient( 'most_recent_user' );
Это, очевидно, вернет любой тип информации, которую вы сохранили, или если переходный период истек — то есть прошло более 12 часов — тогда функция вернет логическое значение FALSE .
Это ключевой момент, который нужно помнить, особенно когда вы пытаетесь прочитать значения кэша, а затем вам нужно получить их из другого источника данных, если они не будут доступны в временном хранилище.
Мы рассмотрим полный пример этого до конца статьи.
Удаление переходных процессов
Наконец, если вам нужно удалить переходный процесс либо полностью удалить его, либо удалить его до истечения срока его действия, чтобы заменить его другим значением, тогда вы просто используете следующую функцию:
delete_transient( 'most_recent_user' );
Кроме того, эта функция вернет FALSE если удаление переходного значения не было успешным; в противном случае он вернет FALSE .
Истекающие переходные процессы
Когда дело доходит до установки времени истечения срока действия значений кэша, существует ряд способов, которые облегчают установку значений, а не основную целочисленную обработку музыки.
Например, MINUTE_IN_SECONDS намного проще в использовании, чем 60, особенно при умножении его на, скажем, минуты, часы или дни.
Начиная с WordPress 3.5, в основное приложение добавлено несколько констант, которые значительно облегчают чтение этих вычислений.
А именно:
-
MINUTE_IN_SECONDS -
HOUR_IN_SECONDS -
DAY_IN_SECONDS -
WEEK_IN_SECONDS -
YEAR_IN_SECONDS
Намного легче использовать, читать и писать, не так ли?
Полный пример использования переходных процессов
На данный момент, я думаю, что важно посмотреть, как мы можем настроить переходные процессы, начнем с сохранения значения в таблице параметров.
Вот порядок, в котором мы будем делать это:
- Мы сохраним опцию в таблице
wp_options. - Далее мы проверим, существует ли значение в кэше.
- Если значение существует в кеше, мы его удалим; в противном случае мы добавим это.
Затем во второй половине кода мы сделаем следующее:
- Мы попытаемся извлечь значение функции из кеша.
- Если значение существует в кэше, мы вернемся к таблице параметров; однако, если значение существует, мы будем его использовать.
С учетом сказанного, давайте посмотрим:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
$username = wp_get_current_user()->user_name;
add_option( ‘most_recent_user’, $username );
// Check to see if the value exists in the cache
if ( FALSE !== get_transient( ‘most_recent_user’ ) ) {
// If it does, we’ll delete it…
if( delete_transient( ‘most_recent_user’ ) ) {
// …and store the most recent user for a maximum of one minute
set_transient( ‘most_recent_user’, MINUTE_IN_SECONDS );
} else {
// The deletion was unsuccessful, so log the error
}
}
// Now try to read the value from the cache.
if ( FALSE !== ( $username = get_transient( ‘most_recent_user’ ) ) {
// Since it doesn’t exist, then we’ll read it from the option’s table
$username = get_option( ‘most_recent_user’ );
// And then we’ll update the cache
set_transient( ‘most_recent_user’, $username, MINUTE_IN_SECONDS );
}
|
Обратите внимание, что этот пример неполон — его можно реорганизовать, чтобы он стал немного чище, и код должен быть абстрагирован в функции, которые более актуальны для приложения, но цель этого кода — показать, как обрабатывать условную логику, параметры и переходные процессы.
Как это сочетается с плагинами?
Теперь, после всего сказанного, мы можем вернуться к вопросу о том, как использование переходных процессов может повысить производительность в плагинах.
Как мы уже упоминали:
После того, как мы рассмотрим доступные API, мы вернемся к этой теме, чтобы увидеть, как они повышают производительность плагинов для кэширования, позже в этой статье.
С учетом сказанного, кеширование и база данных WordPress связаны с расположением данных в базе данных.
Поскольку переходные процессы хранятся в другом месте, чем остальные данные, плагины, такие как, например, плагин на основе memcached , будут искать данные, в которых хранятся переходные процессы, а затем загружать данные в память из этого расположения.
Таким образом, когда данные запрашиваются, они будут извлечены из памяти. Если данные не существуют, они будут извлечены из базы данных.
Кроме того, если программирование выполнено правильно, когда данные не могут быть прочитаны из кеша и извлечены из базы данных, они будут вставлены обратно в кеш, чтобы при следующем получении они были доступны в памяти ,
Наконец, ключевая вещь, которую следует отметить в отношении временной информации, заключается в том, что она имеет срок действия. Это означает, что данные будут храниться в этой области базы данных только в течение определенного периода времени.
Для этого нам необходимо учитывать это. Это означает, что когда бы мы ни искали переходные процессы, мы должны убедиться, что они существуют. Если они этого не сделают, мы вытащим их оттуда, где они находятся , и затем сохраним их в нужном месте.
Пользовательские Запросы
К этому моменту мы рассмотрели множество возможностей, которые предлагает WordPress, поскольку они связаны с основой для разработки веб-приложений.
Но у нас есть последний важный компонент, который нужно охватить, и это то, что нужно делать с пользовательскими запросами.
Конечно, есть несколько отличных API, поскольку они связаны с выполнением запросов, разработанных для конкретных целей WordPress, таких как WP_Query и WP_User_Query , но мы также рассмотрим некоторые нативные средства, которые позволяют нам писать собственные запросы к базе данных, используя определенные Объекты WordPress, а также методы, обеспечивающие правильную очистку данных.
Но мы расскажем обо всем этом и многом другом в следующей статье.