Содержание

MySQL кэширование запросов: максимальный размер кэша ограничен 128 МБ?



Мое приложение очень интенсивно использует базу данных, поэтому я очень старался убедиться, что приложение и база данных MySQL работают как можно эффективнее вместе.

В настоящее время я настраиваю кэш запросов MySQL, чтобы привести его в соответствие с характеристиками запросов, выполняемых на сервере.

query_cache_size — это максимальный объем данных, которые могут храниться в кэше, а query_cache_limit -максимальный размер одного результирующего набора в кэше.

Мой текущий кэш запросов MySQL настроен следующим образом:

query_cache_size=128M
query_cache_limit=1M

tuning-primer.sh дает мне следующие советы по настройке работающей системы:

QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 127 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 99.95 %
Current query_cache_min_res_unit = 4 K
However, 21278 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size

И mysqltuner.pl дает следующие подсказки по настройке:

[OK] Query cache efficiency: 31.3% (39K cached / 125K selects)
[!!] Query cache prunes per day: 2300654

Variables to adjust:
    query_cache_size (> 128M)

Оба сценария настройки предполагают, что я должен поднять query_cache_size . Однако увеличение query_cache size более 128 м может снизить производительность в соответствии с mysqltuner.pl (см. http://mysqltuner.pl/ ).

Как бы вы решили эту проблему? Увеличили бы вы query_cache_size, несмотря на предупреждение mysqltuner.pl, или попытались бы каким-то образом скорректировать логику запроса? Большая часть доступа к данным обрабатывается Hibernate, но в приложении также используется довольно много вручную закодированных SQL.

caching mysql performance innodb
Поделиться Источник knorv     19 января 2010 в 17:43

6 ответов


  • ASP.NET максимальный размер кэша

    Каков максимальный размер кэша ASP.NET (либо deployer на одном сервере, либо out-of-process на веб-ферме), который вы можете иметь? Если существует ограничение на размер кэша ASP.NET, есть ли обходной путь для увеличения этого ограничения? Спасибо Джеймс

  • Каков максимальный размер MySQL VARCHAR?

    Я хотел бы знать, каков максимальный размер для типа MySQL VARCHAR. Я читал,что максимальный размер ограничен размером строки, который составляет около 65 тыс. Я попытался установить поле на varchar(20000) , но оно говорит, что оно слишком велико. Я мог бы установить его на varchar(10000) . Каков…



19

Предупреждение, выданное mysqltuner.py, действительно актуально, даже если ваш кэш не рискует быть замененным. Это хорошо объясняется в следующем: http:/ / blogs.oracle.com / dlutz/entry/mysql_query_cache_sizing

В основном MySQL тратит больше времени на уход за кэшем, чем больше кэш, и поскольку Кэш очень волатилен даже при умеренных нагрузках на запись (запросы часто очищаются), его слишком большой размер отрицательно скажется на производительности вашего приложения. Настройте query_cache_size и query_cache_limit для вашего приложения, попробуйте найти критическую точку, где у вас больше всего обращений на вставку, низкое число lowmem_prunes и внимательно следите за нагрузкой серверов баз данных, делая то же самое.

Поделиться mikn     27 ноября 2011 в 23:24



15

Обычно предупреждения «too big cache size» выдаются в предположении, что у вас мало физической памяти и сам кэш хорошо нуждается в замене или займет ресурсы, которые требуются OS (например, файловый кэш).

Если у вас достаточно памяти, можно безопасно увеличить query_cache size (я видел установки с кэшем запросов 1GB ).

Но вы уверены, что правильно используете кэш запросов? У вас есть много дословно повторяющихся запросов? Не могли бы вы опубликовать пример типичного запроса?

Поделиться Quassnoi     19 января 2010 в 17:53



14

Вы должны быть легки в увеличении своего кэша, это не только «not that much available mem» вещь!

Значение, например инструкция вам эта цитата:

Будьте осторожны с чрезмерно большим размером кэша запросов, что увеличивает накладные расходы, необходимые для поддержания кэша, возможно, за пределами преимуществ его включения. Размеры в десятки мегабайт обычно выгодны. Размеров в сотни мегабайт может и не быть.

Есть и другие источники , которые вы можете проверить!

Ненулевая скорость обрезки может указывать на то, что вам следует увеличить размер кэша запросов. Однако имейте в виду, что накладные расходы на поддержание кэша, скорее всего, увеличатся с его размером, поэтому делайте это небольшими шагами и следите за результатом. Если вам нужно резко увеличить размер кэша, чтобы исключить чернослив, есть хороший шанс, что ваша рабочая нагрузка не очень хорошо подходит для кэша запросов.

Так что не просто кладите столько, сколько сможете, в этот кэш запросов!

Лучше всего было бы постепенно увеличивать кэш запросов и измерять производительность на вашем сайте. Это своего рода дефолт в вопросах производительности, но в таких случаях ‘testing’-одна из лучших вещей, которые вы можете сделать.

Поделиться Nanne     27 марта 2013 в 16:32


  • Каков максимальный размер кэша для iOS6 веб-приложений и как его можно расширить?

    Я создаю веб-приложение специально для iPad (работает iOS 6+), показывающее коллекцию продуктов компании. Все это прекрасно работало с использованием файла HTML5 cache.manifest. Но поскольку кэш вырос примерно до 50 МБ, iPad больше не сохраняет данные приложения. Вместо 50 Мб размер кэша теперь…

  • Максимальный размер файла PHP MYSQL

    В моем файле php.ini мой максимальный размер составляет 1 Мб. Однако, когда я вставляю blob в свою базу данных mysql, она отсекает его на 64 КБ. Как я могу увеличить максимальный размер файла? Примечание: изображение буквально отрезано на 64 КБ, оно отображает кусочек изображения.



5

Будьте осторожны с установкой query_cache_size и limit на high. MySQL использует только один поток для чтения из кэша запросов.

С query_cache_size равным 4G и query_cache_limit 12M мы имели скорость кэширования запросов 85%, но заметили повторяющиеся всплески в соединениях.

После изменения query_cache_size на 256M с 64K

query_cache_limit коэффициент кэша запросов снизился до 50%, но общая производительность увеличилась.

Поделиться Brian van Rooijen     12 февраля 2016 в 15:08



4

Накладные расходы для кэша запросов составляют около 10%, поэтому я бы отключил кэширование запросов. Обычно, если вы не можете получить свою скорость попадания более 40 или 50%, возможно, кэш запросов не подходит для вашей базы данных.

У меня есть блог на эту тему … Mysql query_cache_size performance здесь .

Поделиться Hayden     21 апреля 2013 в 17:57



3

Кэш запросов становится недействительным / сбрасывается каждый раз, когда происходит вставка, используйте InnoDB/cache и избегайте кэша запросов или установите для него очень маленькое значение.

Поделиться PePe     16 июля 2013 в 05:32


Похожие вопросы:


Максимальный размер iPad / iPhone автономного кэша приложений

Любой знает максимальный размер автономного кэша приложений Safari на iPad & iPhone. Похоже, что это 5 Мб. Есть ли способ увеличить этот размер? Автономный кэш приложений docs: https: / /…


Определите максимальный размер кэша временных Интернет-файлов пользователя Chrome

Как программно определить максимальный размер кэша временных Интернет-файлов пользователя Chrome? У нас есть простое настольное приложение, которое пользователь запускает для получения разнообразной…


Максимальный размер кэша

Я планирую сохранить открытый файл в кэш android. Но прежде чем я начну, я хочу знать максимальный размер файла кэша, и как я могу управлять размером кэша в зависимости от устройства?


ASP.NET максимальный размер кэша

Каков максимальный размер кэша ASP.NET (либо deployer на одном сервере, либо out-of-process на веб-ферме), который вы можете иметь? Если существует ограничение на размер кэша ASP.NET, есть ли…


Каков максимальный размер MySQL VARCHAR?

Я хотел бы знать, каков максимальный размер для типа MySQL VARCHAR. Я читал,что максимальный размер ограничен размером строки, который составляет около 65 тыс. Я попытался установить поле на…


Каков максимальный размер кэша для iOS6 веб-приложений и как его можно расширить?

Я создаю веб-приложение специально для iPad (работает iOS 6+), показывающее коллекцию продуктов компании. Все это прекрасно работало с использованием файла HTML5 cache.manifest. Но поскольку кэш…


Максимальный размер файла PHP MYSQL

В моем файле php.ini мой максимальный размер составляет 1 Мб. Однако, когда я вставляю blob в свою базу данных mysql, она отсекает его на 64 КБ. Как я могу увеличить максимальный размер файла?…


Firebase Realtime Database максимальный размер кэша в Android

Каков максимальный размер кэша Firebase Realtime Database для клиента Android? Ограничено ли оно Firebase или Android? Firebase документация гласит:: По умолчанию 10 МБ ранее синхронизированных…


Mongodb максимальный размер коллекции ограничен?

Я использовал Mongodb с php.. у меня есть некоторые сомнения по поводу Mongodb это, каков максимальный размер (в КБ или мб) коллекции ? и на сайте mongodb я видел maximum document size is 16mb..so…


wordpress максимальный размер загрузки не меняется

Мне нужно изменить максимальный размер загружаемого файла WordPress на что-то большее, чем 2 Мб. Я изменил максимальный размер загружаемого файла в настройках Мультисайта на 19500. Я также…

Настройка работы MySQL Query Cache

Использование кэширования запросов, является одним из ключевых факторов влияющих на производительность работы MySQL. Функционал Query Cache открывает дополнительные возможности для оптимизации базы данных и позволяет снизить время обработки запросов в несколько раз. Наилучшую эффективность работы Query Cache показывает на веб-серверах, у которых таблицы не обновляются слишком часто и присутствует много идентичных запросов.

Для подходящего запроса типа SELECT, MySQL автоматически сохраняет текст запроса и данные выборки в кэше. Все идентичные запросы в дальнейшем, будут обрабатываться в обход БД с помощью функции MySQL Query Cache. Таким образом, кэшированные запросы не выполняется вовсе.

Для работы Query Cache в значении переменной query_cache_type должно быть установлено ON или DEMAND, а query_cache_size быть отличной от нуля.

В противном случае, необходимо добавить соответствующие настройки в секцию [mysqld] конфигурационного файла MySQL:

nano /etc/mysql/my.cnf

[mysqld]
query_cache_type        = ON
query_cache_limit       = 1M
query_cache_size        = 16M

За настройку работы функции Query Cache отвечают системные переменные начинающиеся с 'query_cache_'.

mysql> SHOW VARIABLES LIKE 'query_cache_%';

+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+
5 rows in set (0.00 sec)

query_cache_limit — размер максимальной выборки, которая будет записана в кэш. В качестве значения необходимо указать максимальный размер самого тяжелого запроса, но не стоит чрезмерно завышать значение данного параметра.
query_cache_min_res_unit — минимальный размер выделяемого блока памяти для хранения результатов кэшированного запроса. Для записи данных в кэш MySQL разбивает выборку на отдельные блоки с минимальным размером query_cache_min_res_unit. Последний такой блок обрезается до размера данных, а оставшаяся память освобождается. Для записи данных в кэш, MySQL по мере необходимости выделяет блоки размером query_cache_min_res_unit. В качестве значения необходимо указать среднее значение размера выборки от всех запросов. Примерное значение query_cache_min_res_unit можно вычислить по формуле query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache. Слишком большое значение будет способствовать фрагментации кэша, слишком маленькое может стать причиной снижения производительности.
query_cache_size — размер памяти выделяемый для хранения кэша запросов. Значение равное 0 отключает работу MySQL Query Cache. Устанавливаем значение исходя из количества свободной оперативной памяти в системе. Для выбора оптимального значения, в идеале переменная Qcache_lowmem_prunes должна равняться нулю. В противном случае, рекомендуется чтобы в процессе работы MySQL это значение увеличивалось незначительно.
query_cache_type — параметр отвечающий за работу кэша. Может принимать значения: ON, DEMAND и OFF. Опция включает или отключает работу MySQL Query Cache, если значение query_cache_type установлено равным DEMAND, MySQL будет кэшировать только запросы с директивой SQL_CACHE.
query_cache_wlock_invalidate — определяет будут ли данные браться из кэша, если таблица, к которым они относятся заблокирована на чтение. Если значение параметра query_cache_wlock_invalidate принимает значение OFF, то будет доступно получение данных заблокированной таблицы из Query Cache.

Для мониторинга MySQL Query Cache используется команда:

mysql> SHOW GLOBAL STATUS LIKE 'Qcache%';

+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 158      |
| Qcache_free_memory      | 16420704 |
| Qcache_hits             | 143791   |
| Qcache_inserts          | 21851    |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 12506    |
| Qcache_queries_in_cache | 215      |
| Qcache_total_blocks     | 598      |
+-------------------------+----------+
8 rows in set (0.00 sec)

Qcache_free_blocks — количество свободных блоков в кэше. Чем больше незадействованных блоков, тем больше степень фрагментации кэша. Если результат большинства запросов имеет небольшой объем данных выборки, необходимо уменьшить значение параметра query_cache_min_res_unit.
Qcache_total_blocks — количество занятых блоков.
Qcache_free_memory — объем свободной памяти, отведенной под кэш.
Qcache_hits — количество запросов отработанных из кэша.
Qcache_inserts — количество запросов записанных в кэш.
Qcache_lowmem_prunes — количество запросов, которые были удалены из-за переполнения кэша.
Qcache_not_cached — количество запросов не подлежащих кэшированию.
Qcache_queries_in_cache — количество запросов находящихся в кэше.

Кратко механизм работы Query Cache выглядит следующим образом. Под кэширование запросов MySQL выделяет в памяти область размером query_cache_size. Для записи результатов запроса сервер создает в кэше свободный блок размером query_cache_min_res_unit. После заполнения блока, сервер создает новый пустой блок и так до тех пор, пока все данные выборки не будут записаны в кэш. После чего свободная область памяти последнего блока выделяется в новый свободный блок. В случае если размер выборки превышает установленное значение query_cache_limit, то запись прекращается, а занятое память освобождается.

Фрагментация кэша возникает при удалении выборки из кэша, когда для записи результатов новых запросов количества освободившихся блоков недостаточно. Для того что бы определить степень фрагментации, необходимо обратить внимание на значение переменной Qcache_free_blocks. В идеале значение должно быть равно единице, в случае фрагментации — Qcache_total_blocks / 2. Так же можно определить, что ваш кэш запросов сильно фрагментируется, если значение Qcache_lowmem_prunes постоянно возрастает при том, что значение Qcache_free_memory далеко от нуля.

Для дефрагментации кэша используется команда:

mysql> FLUSH QUERY CACHE;

Для оценки эффективности работы кэша используется формула Qcache_hits / (Qcache_hits + Com_select).

кеш запросов mysql — Русские Блоги

Если после включения кеша mysql данные не обновляются, тот же запрос sql будет использовать кэшированные данные для возврата результатов. В случае меньшего количества обновлений данных и большего количества похожих запросов использование кэша mysql может значительно повысить эффективность запросов.

Настройки параметров кеша запросов mysql

(1) have_query_cache указывает, поддерживается ли кеширование запросов, а YES указывает на поддержку.

(2) query_cache_type указывает тип кеша, OFF указывает, что кеш запросов выключен, ON указывает, что кеш запросов включен, а DEMAND указывает кеш запросов, определенный пользователем.

(3) query_cache_limit указывает максимальный объем поддерживаемых данных sql для одного запроса.

(4) query_cache_min_res_unit представляет минимальную единицу кеша запросов.

(5) query_cache_size представляет размер пространства кэша запроса.

(6) query_cache_wlock_invalidate указывает, поддерживает ли кеш запроса блокировки записи, OFF указывает на отсутствие поддержки, то есть чтение данных не учитывает блокировки записи, ON указывает на поддержку, то есть чтение данных будет заблокировано блокировками записи

Использование кеша запросов

(1) Только запрос sql с равными строками использует один и тот же кеш, то есть, выберите имя из города и выберите имя из города не использовать один и тот же кеш.

(2) Когда query_cache_type включен, все запросы по умолчанию используют кеш, мы можем использоватьsql_no_cacheПоказать, что определенный запрос не использует кеш

select sql_no_cache name from city;

(3) Когда query_cache_type является DEMAND, вам необходимо использоватьsql_cacheУкажите запрос для использования кеша

select sql_cache name from city;

Запрос на использование кеша

Переменные кеша запросов можно установить только в файле my.ini.

Выполнить оператор запроса: выбрать имя sql_cache из города;

Выполнить статус показа, например, «Qcache%»;

 

(1) Qcache_free_blocks указывает количество свободных блоков в выделенном блоке памяти;

(2) Qcache_total_blocks представляет количество блоков памяти, занятых текущим кешем запроса;

(3) Qcache_free_memory представляет размер свободного пространства кеша;

(4) Qcache_hits представляет количество попаданий в кэш;

(5) Qcache_inserts указывает, сколько раз данные были записаны в кэш, когда кэш был пропущен;

(6) Qcache_queries_in_cache представляет количество кэшированных операторов запроса;

(7) Qcache_lowmem_prunes представляет количество сокращений кеша. Когда кеш заполнен, алгоритм LRU будет использоваться для удаления самого длинного неиспользуемого кеша. Это значение велико, что указывает на то, что пространство кеша слишком мало;

(8) Qcache_not_cached представляет количество запросов sql, которые не кэшируются.

Скорость фрагментации кеша запросов =(Qcache_free_blocks / Qcache_total_blocks)* 100%

Если значение Qcache_free_blocks слишком велико, чем выше скорость фрагментации, это доказывает, что наша кеш-память немного более фрагментирована. Вы можете попытаться соответствующим образом уменьшить значение query_cache_min_res_unit, или вы можете использовать инструкцию FLUSH QUERY CACHE для очистки кеша фрагменты.

Использование кеша запросов = (query_cache_size — Qcache_free_memory) / query_cache_size  * 100%

Если коэффициент использования кэша запросов слишком низкий, это означает, что параметр query_cache_size может быть слишком большим и может быть соответствующим образом скорректирован. Если коэффициент использования кеша очень высок, а значение Qcache_lowmem_prunes относительно велико, это означает, что значение query_cache_size устанавливается немного меньше.

Расчетное значение query_cache_min_res_unit относится к формуле расчета: (query_cache_size-Qcache_free_memory) / Qcache_queries_in_cache

Частота попаданий в кеш запросов  = (Qcache_hits / Com_select)* 100%

Com_select в приведенной выше формуле представляет количество выполнений оператора запроса (это описание неточно), вы можете использовать следующий оператор, чтобы получить количество выполнений оператора запроса

show status like ‘Com_select%’;

Сбросить кеш

reset query cache;

Перепечатано по адресу: https://www.cnblogs.com/coshaho/p/7192343.html

MySQL кеш запросов — Русские Блоги

 

Кеш запросов,ЗакэшSQLОператор запроса иSQLВ соответствии с заявлениемРезультат установлен.

 

когдаMySQLКогда тот же запрос будет получен снова, он начнется сКеш запросовРезультаты поиска вВместо анализа и выполнения этого же запроса снова. 

 

При получении результатов из кеша запросов,матчСтандарт это:SQLВыражения идентичны (с учетом регистра).

 

 

Проверьте токMySQLНезависимо от того, чтобы поддерживать кэш запросов

show variables like ‘have_query_cache’;



  

Описание:

have_query_cache=YESЗначит токMySQLКэш запросов поддерживается, но это не означает, что он включен. Эта переменная доступна только для чтения и не может быть изменена пользователями.

поsetМодификация команды сообщит об ошибке:ERROR 1238 (HY000): Variable ‘have_query_cache’ is a read only variable

 

 

Включить кеширование запросов

Ли включитьmysqlКеш запросов, вы можете передать2Параметры:query_cache_typeсquery_cache_size,Установить,Любой из этих параметров установлен в0Все средства отключают кеширование запросов。

 

вmysqlПрофиль[mysqld]  Часть, измените следующие элементы конфигурации (добавьте вручную, если нет):

query_cache_size=10M

query_cache_type=1

 

После настройки перезагрузитеmysqlА потом пройтиshow variables like ‘%query_cache%’Посмотреть:



  

 

Описание:

(1)query_cache_typeЕсть3Ценность:

 

0илиoff, От имени закрытых

 

1илиonЧто означает открытый

вonВ режиме, если вы не хотите использовать кеш, вам нужно передатьsql_no_cacheКлючевые словаПриходитьУказанные инструкции,

Такие какselect sql_no_cache id,name from tableName;

 

 

2 илиdemand, Следует ли включить кэширование по мере необходимости.

когдаsqlВ заявленииSQL_CACHEКэшировать только при наличии ключевых слов,

Такие как:select SQL_CACHE user_name from users where user_id = ‘100’;

 

В любом режиме, когдаsqlИспользуется вmysqlФункция, она не будет кешироваться.

 

(2)query_cache_sizeПредставляет общий объем памяти, выделенный для кэша запросов,Значение не настолько велико, насколько это возможно, его необходимо установить в соответствии с реальной ситуацией (здесь не подробно)

 

(3)query_cache_limit Результат одного запроса больше этого значения, и кеш больше не кешируется. Значением по умолчанию является1048576, который1M。

(4)query_cache_min_res_unit Минимальный размер выделенного блока кэша, по умолчанию 4 КБ, установленоОгромное значение,Подходит для запросов больших данных, но если ваши запросы представляют собой небольшие запросы данных, легко вызвать фрагментацию памяти и потерю。

(5)query_cache_wlock_invaliate  По умолчанию установлено значение OFF, вы можете прочитать кэшированные данные заблокированной таблицы

 

 

 

Посмотреть кеш



  

 

Значение каждого параметра следующее: 
Qcache_free_blocks:Указывает, сколько в данный момент осталось в кэше запросов.blocks, Если значение больше, ноQcache_lowmem_prunesНо это продолжает расти, тогдаобъяснениеВ кеше запросов слишком много фрагментации. (FLUSH QUERY CACHE отсортирует фрагменты в кэше, чтобы получить бесплатный блок)。 
Qcache_free_memory: свободная память в кеше.
Qcache_hits: увеличивается каждый раз, когда запрос попадает в кеш
Qcache_inserts: вставлять по одному запросу за разкэшВремя увеличивается.

Qcache_lowmem_prunes: количество раз, когда кэш имеет недостаточно памяти и должен быть очищен, чтобы обеспечить место для большего количества запросов. Лучше всего долго смотреть на это число, если оно продолжает расти, это означает, что фрагментация может быть очень серьезной или мало памяти. (Free_blocks и free_memory выше могут сказать вам, какая ситуация)
Qcache_not_cached: количество запросов, которые не подходят для кэширования, обычно потому, что эти запросы не являются операторами SELECT или используют функции, такие как now ().
Qcache_queries_in_cache:В текущем кеше кеш (selectутверждение+Набор результатов)количество。 
Qcache_total_blocks: количество блоков в кеше

 

выключивblockКусок

Когда QC кэширует результат запроса, как правило, недостаточно выделить достаточно памяти для одновременного кэширования результатов. Он сохраняется блок за блоком в процессе получения результатов запроса. Когда блок хранения заполнен, будет создан новый блок хранения и выделена память (выделить). Размер выделения памяти одного блока хранения контролируется параметром query_cache_min_res_unit, который по умолчанию равен 4 КБ. Если последний блок хранения не может быть использован полностью, неиспользуемая память будет освобождена. Если кэшированный результат очень большой, это может привести к тому, что операция выделения памяти будет слишком частой, и производительность системы будет соответственно уменьшаться, а если кэшированный результат очень маленький, это может вызвать слишком большую фрагментацию памяти, если эти фрагменты слишком Если он небольшой, он не может быть снова выделен для использования.

В дополнение к блокам хранения, необходимым для результатов запроса, для каждого текста SQL также требуется блок хранения, а для задействованных таблиц также требуется блок хранения (блок хранения таблицы является общим для всех потоков, и для каждой таблицы требуется только один блок хранения).Общее количество блоков хранения = количество результатов запроса * 2+ количество задействованных таблиц базы данных, То есть, когда генерируется первый кэш, необходимы по меньшей мере три блока хранения: блок хранения табличной информации, блок хранения текста SQL и блок хранения результата запроса. Если во втором запросе используется одна и та же таблица, необходимы как минимум два блока хранения: блок хранения текста SQL и блок хранения результатов запроса.

Наблюдая за Qcache_queries_in_cache и Qcache_total_blocks, вы можете узнать средний блок памяти, занимаемый каждым результатом кэша. Если их соотношение близко к 1: 2, это означает, что текущий параметр query_cache_min_res_unit уже достаточно велик. Если Qcache_total_blocks намного больше, чем Qcache_queries_in_cache, вам нужно увеличить размер query_cache_min_res_unit.

 

   

 

О кеше запросов,mysqlОфициальные инструкции:

# Query cache is used to cache SELECT results and later return them

# without actual executing the same query once again. Having the query

# cache enabled may result in significant speed improvements, if your

# have a lot of identical queries and rarely changing tables. See the

# «Qcache_lowmem_prunes» status variable to check if the current value

# is high enough for your load.

# Note: In case your tables change very often or if your queries are

# textually different every time, the query cache may result in a

# slowdown instead of a performance improvement.

перевести на китайский:

Кеш запросов используется для кешированияselectВ результате, когда снова возникает тот же запрос, кэшированный результат может быть возвращен напрямую, без фактического повторного выполнения запроса. Если у вас большое количество одинаковых запросов и вы редко меняете данные в таблице, использование кэша может значительно повысить скорость отклика. По просмотруQcache_lowmem_prunesMsgstr «Статус, вы можете проверить, достаточно ли текущего пространства кеша.

Примечание. Если данные в таблице изменяются чаще или ваш запрос каждый раз отличается, использование кеша запросов в это время может привести к снижению производительности, а не к повышению производительности.

 

 

Запросите дефрагментацию области кэша:

После того, как кэш запросов используется в течение определенного периода времени, обычно происходит фрагментация памяти.Для этого необходимо контролировать связанные значения состояний и регулярно организовывать фрагментацию памяти.FLUSH QUERY CACHE;

 

пустойКеш запросовПлощадь:

1、RESET QUERY CACHE;

или

 2、FLUSH TABLES;



  

 

 

дополнение

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

(2) Кеш запросовПрименимо к ситуации, когда таблица не изменяется слишком часто и имеется большое количество одного и того же запроса.

 

MySQL/MariaDB: тюнинг производительности #4: query_cache_size

Среди прочих данных tuning-primer сообщает что:

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

query_cache — это область памяти, выделяемая MySQL при старте, в которой хранятся запросы и их результаты типа SELECT. При получении нового запроса SELECTMySQL сначала проверяет нет ли такого же запроса в этом кеше и, если есть, возвращает значение из памяти, иначе — выполняет обращение к базе (и диску). Обратите внимание, что select * FROM и SELECT * FROM для кеша MySQL являются двумя различными запросами.

Кеш запросов поддерживается в MySQL версий > 4.0:

MariaDB [(none)]> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+

По умолчанию query_cache отключён, что можно проверить так:

MariaDB [(none)]> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_size | 0     |
+------------------+-------+

Qcache может иметь три состояния:

MariaDB [(none)]> SHOW VARIABLES LIKE 'query_cache_type';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_type | ON    |
+------------------+-------+
  • 0 (OFF) — Qcache отключён;
  • 1 (ON) — Qcache включен;
  • 2 (DEMAND) — только для запросов с явным указанием его кеширования (SELECT SQL_CACHE).

Что бы включить его — достаточно установить query_cache_size в любое положительное значение, отличное от нуля.

В настройке Qcache главную роль играют три параметра:

  • query_cache_size — размер памяти, выделяемый под кеш;
  • query_cache_type — см. выше;
  • query_cache_limit — максимальный размер возвращаемого результата запроса, который будет хранится в кеше.

Устанавливаем query_cache_size = 16 МБ, query_cache_type = 1 а query_cache_limit — оставляем по умолчанию, 1 МБ:

MariaDB [(none)]> SET GLOBAL query_cache_size=16*1024*1024;
MariaDB [(none)]> SET GLOBAL query_cache_type=1;
Query OK, 0 rows affected (0.00 sec)

Проверяем:

MariaDB [(none)]> SHOW VARIABLES LIKE '%query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 |
| query_cache_strip_comments   | OFF      |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

Через какое-то время, хотя бы час, проверяем статус:

MariaDB [(none)]> SHOW STATUS LIKE 'qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 176      |
| Qcache_free_memory      | 13628632 |
| Qcache_hits             | 9935     |
| Qcache_inserts          | 4537     |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 2614     |
| Qcache_queries_in_cache | 392      |
| Qcache_total_blocks     | 1069     |
+-------------------------+----------+

В последней выборке нас интересуют:

  • Qcache_free_memory — доступное место в кеше;
  • Qcache_hits — количество запросов, отработанных из кэша;
  • Qcache_inserts — количество добавлений запросов в кэш;
  • Qcache_not_cached — количество запросов, не подлежащих кэшированию;
  • Qcache_lowmem_prunes — количество высвобождений памяти из-за наполненности кэша.

Теперь посчитаем % использования кеша:

Qcache_free_memory * 100 / query_cache_size — дадут нам % свободного места в query_cache_size:

>>> 13694488.0 * 100 / 16777216.0
81.625509262084961

81.6% свободно.

Или наоборот — % занятого места:

((query_cache_size-Qcache_free_memory)/query_cache_size)*100

>>> ((16777216.0 - 13694488.0) / 16777216.0) * 100
18.374490737915039

Т.е. занято 18.37%. Смысла в увеличении пока нет.

Что бы убедиться в этом — подсчитаем ещё такое значение как «Query Cache Hit Rate» по формуле:

((Qcache_hits/(Qcache_hits+Qcache_inserts+Qcache_not_cached))*100)

Получаем такое значение:

>>> (9935.0 / (9935.0 + 4537.0 + 2614.0)) * 100
58.147020952826878

Т.е. — MySQL обращался к кешу 17086 раз (Qcache_hits+Qcache_inserts+Qcache_not_cached), и 9935 запросов были выданы из кеша, следовательно Query Cache Hit Rate = 58%.

Это не самое хорошее значение, однако — пока оно выше 50% — query_cache_size можно не менять. Если значение менее 50% — можно увеличить размер кеша, а если же значение ниже 10-20% — то, возможно, Qcache лучше не использовать вообще.

Ещё два важных значения — это соотношение значений Qcache_hits/Qcache_inserts и Qcache_inserts/Qcache_lowmem_prunes.

Из примера выше — для Qcache_hits/Qcache_inserts получаем такое значение:

>>> 11386.0 / 5697.0
1.9985957521502544

Т.е. — в среднем каждый добавленный в кеш результат был выдан клиентам 2 раза. Чем ближе значение к соотношению 1:1 (или даже меньше, напрмиер — 0.5:1) — тем меньше эффективность работы кеша.

Второе значение Qcache_inserts/Qcache_lowmem_prunes — из примера выше получить не выйдет (т.к. Qcache_lowmem_prunes = 0), поэтому — возьмём значение с другой базы другого сервера:

mysql> SHOW STATUS LIKE 'qcache%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
...
| Qcache_inserts          | 2773956 |
| Qcache_lowmem_prunes    | 1417292 |

Результат:

>>> 2773956.0 / 1417292.0
1.957222647132701

Т.е. — фактически, каждый второй запрос и результат, добавленные в кеш, были удалены.

Можно посчитать процентное соотношение:

>>> 1417292.0 * 100 / 2773956.0
51.092807528309748

Итого — процент удалений кеша равен 51%, тогда как более-менее оптимальным считается значение 10-20% удалений.

Эти же данные можно получить в выводе утилиты mysqlreport:

$ mysqlreport --user root --password password | less
...
__ Query Cache _________________________________________________________
Memory usage    3.48M of   8.00M  %Used:  43.46
Block Fragmnt   4.13%
Hits            1.35M     0.8/s
Inserts         2.96M     1.8/s
Insrt:Prune    1.95:1     0.9/s
Hit:Insert     0.46:1
...

По теме:

http://www.techinfobest.com

http://haydenjames.io

http://goldapplesoftware.ca


HTTP-кеширование — HTTP | MDN

Производительность веб-сайтов и приложений можно значительно повысить за счёт повторного использования ранее полученных ресурсов. Веб-кеши сокращают задержку и снижают сетевой трафик, уменьшая тем самым время, необходимое для отображения ресурсов. Используя HTTP-кеширование, сайты становятся более отзывчивыми.

Техника кеширования заключается в сохранении копии полученного ресурса для возврата этой копии в ответ на дальнейшие запросы. Запрос на ресурс, уже имеющийся в веб-кеше, перехватывается, и вместо обращения к исходному серверу выполняется загрузка копии из кеша. Таким образом снижается нагрузка на сервер, которому не приходится самому обслуживать всех клиентов, и повышается производительность — кеш ближе к клиенту и ресурс передаётся быстрее. Кеширование является основным источником повышения производительности веб-сайтов. Однако, кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется хранить только до того момента, как ресурс изменился, но не дольше.

Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надёжности, производительности и масштабируемости веб-сайтов и веб-приложений.

 

Приватный (private) кеш браузера

Приватный кеш предназначен для отдельного пользователя. Вы, возможно, уже видели параметры кеширования в настройках своего браузера. Кеш браузера содержит все документы, загруженные пользователем по HTTP. Он используется для доступа к ранее загруженным страницам при навигации назад/вперёд, позволяет сохранять страницы, или просматривать их код, не обращаясь лишний раз к серверу. Кроме того, кеш полезен при отключении от сети.

Общий (shared) прокси-кеш

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

Кеширование в HTTP не является обязательным, однако в большинстве случаев бывает полезно повторно использовать ранее сохранённые ресурсы. Тем не менее, стандартные кеши HTTP обычно способны кешировать только ответы на запросы методом GET, а другие отклоняют.

Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:

  • Успешно загруженные ресурсы: ответ 200 OK на запрос методом GET HTML-документов, изображений или файлов.
  • Постоянные перенаправления: ответ 301 Moved Permanently («перемещено навсегда»).
  • Сообщения об ошибках: ответ 404 Not Found («не найдено»).
  • Неполные результаты: ответ 206 Partial Content («частичное содержимое»).
  • Ответы на запросы отличные от GET, если есть что-либо, подходящее для использования в качестве ключа кеша.

Запись в кеше может также состоять из множества ответов, различаемых по вторичному ключу, если при формировании ответа производится согласование данных. Подробнее об этом рассказано ниже, в разделе, посвящённом заголовку Vary.

Заголовок

Cache-control

Поле Cache-Control общего заголовка HTTP/1.1 используется для задания инструкций по механизму кеширования как в запросах, так и в ответах. Применяется для задания политик кеширования.

Полное отсутствие кеширования

В кеше не должно сохраняться ничего — ни по запросам клиента, ни по ответам сервера. Запрос всегда отправляется на сервер, ответ всегда загружается полностью.

Cache-Control: no-store
Cache-Control: no-cache, no-store, must-revalidate
Кешировать, но проверять актуальность

Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.

Cache-Control: no-cache
Приватные (private) и общие (public) кеши

Директива «public» указывает, что ответ можно сохранять в любом кеше. Это бывает полезно, если возникает потребность сохранить страницы с HTTP-аутентификацией, или такими кодами ответа, которые обычно не кешируются. Директива же «private» указывает, что ответ предназначен отдельному пользователю и не должен храниться в кеше совместного использования. В этом случае ответ может сохраняться приватным кешем браузера.

Cache-Control: private
Cache-Control: public
Срок действия (Expiration)

Самой важной здесь является директива «max-age=<seconds>» — максимальное время, в течение которого ресурс считается «свежим». В отличие от директивы Expires, она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять «агрессивное» кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).

Подробнее об этом рассказывается в разделе Свежесть ресурса.

Cache-Control: max-age=31536000
Проверка актуальности

При использовании директивы «must-revalidate» кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.

Cache-Control: must-revalidate

Заголовок

Pragma

Pragma является заголовком HTTP/1.0. Он не описан для HTTP-ответов и, таким образом, не может служить надёжной заменой общему заголовку Cache-Control протокола HTTP/1.1, хотя его поведение аналогично «Cache-Control: no-cache» когда поле заголовка Cache-Control опущено в запросе. Использовать его следует только для совместимости с клиентами HTTP/1.0.

Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять.  Этот процесс называют вытеснением данных из кеша (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохранённой копии. До его истечения ресурс считается свежим (fresh), после — устаревшим (stale). Алгоритмы вытеснения отдают предпочтение «свежим» ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении её срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком If-None-Match (en-US) на случай, если копия все ещё актуальна. Если это так, сервер возвращает заголовок 304 Not Modified («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.

Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:

Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок «Cache-control: max-age=N», то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок Expires, и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified.  Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.
Время устаревания (expirationTime) вычисляется следующим образом:

expirationTime = responseTime + freshnessLifetime - currentAge

где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.

Обновление статических ресурсов (Revved resources)

Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их «срок годности» имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.

Веб-разработчики разработали метод, который Стив Сандерс (Steve Sounders) назвал revving[1], что можно перевести как «оборачиваемость». Для редко обновляемых файлов используют особый способ именования: в их URL, обычно в имя файла, добавляют номер релиза или версии. Таким образом, каждая новая версия считается отдельным ресурсом, срок устаревания которого отодвинут далеко в будущее, как правило, на год, или больше. Недостатком этого метода является то, что для получения новых версий ресурса приходится обновлять все ссылки на него — это некоторое усложнение, справиться с которым разработчику помогает цепочка инструментов. Обновление статических ресурсов влечёт за собой обновление и часто изменяемых ресурсов. Когда считываются первые, считываются и новые версии вторых.

Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе с новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.

Номер версии, добавляемый к статическому ресурсу, не обязательно записывать в виде стандартного номера версии наподобие 1.1.3, или другого возрастающего числового значения. Это может быть что угодно, позволяющее избежать совпадений — например, дата.

Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок «Cache-control: must-revalidate». Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.

При истечении срока годности документа он либо проходит валидацию, либо повторно доставляется с сервера. Валидация может выполняться только если на сервере реализован сильный валидатор или слабый валидатор.

Заголовки ETag

Заголовок ответа ETag является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок ETag, клиент может транслировать его значение через заголовок If-None-Match (en-US) будущих запросов для валидации кешированного ресурса.

Заголовок ответа Last-Modified можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified, то для валидации кешированного документа клиент может выводить в запросах заголовок  If-Modified-Since.

При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ 200 OK, либо вернуть ответ 304 Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.

Заголовок HTTP-ответа Vary определяет, как по заголовкам будущих запросов понять, может ли быть использована копия из кеша, или нужно запросить новые данные у сервера.

Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком Vary, то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.

Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).

Vary: User-Agent

Поскольку значение заголовка User-Agent (en-US) различается («varies») у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.

Запрос занимает больше времени для завершения работы, если размер кэша TokenAndPermUserStore растет в SQL Server 2005

Номер ошибки: 429501 (SQLBUDT)
Номер ошибки: 429501 (SQL BU отслеживания дефектов)ошибка #: 64830 (Content Maintenance)

Симптомы

В Microsoft SQL Server 2005 могут возникнуть следующие проблемы:

  • Запросы, которые обычно выполняются быстрее занять больше времени для завершения выполнения.

  • Кроме обычных ЦП для процесса SQL Server.

  • Когда вы снижение производительности при выполнении нерегламентированных запросов, Просмотр запроса из динамического административного представления sys.dm_exec_requests или sys.dm_os_waiting_tasks . Тем не менее запрос не ожидания для каждого ресурса.

  • Размер хранилища кэша TokenAndPermUserStore растет с постоянной скоростью.

  • Размер хранилища кэша TokenAndPermUserStore — в нескольких сотен мегабайт (МБ).

  • В некоторых случаях выполнение команды DBCC FREEPROCCACHE предоставляет временное Облегчение.

Чтобы отслеживать размер кэша TokenAndPermUserStore, можно использовать запрос следующего вида:

SELECT SUM(single_pages_kb + multi_pages_kb) AS    "CurrentSizeOfTokenCache(kb)" 
FROM sys.dm_os_memory_clerks
WHERE name = 'TokenAndPermUserStore'

Причина

Хранилища кэша TokenAndPermUserStore поддерживает типы маркеров безопасности соответствовать:

  • LoginToken

  • TokenPerm

  • UserToken

  • SecContextToken

  • TokenAccessResult.

Также присутствуют различные классы элементов TokenAccessResult. Данная проблема возникает из-за много записей TokenAccessResult с классами 65535 присутствуют.

На экземпляре SQL Server, высокая частота выполнения случайных динамический запрос можно заметить, большое количество TokenAccessResult операции с классами 65535 в представление sys.dm_os_memory_cache_entries . TokenAccessResult операции с классами 65535 представляют специальный кэш записи. Эти записи кэша, используются для проверки накопительное разрешений для запросов. Например можно запустить следующий запрос:

select * from t1 join t2 join t3

В этом случае SQL Server вычисляет проверка накопительное разрешений для данного запроса. Этот флажок определяет, имеет ли пользователь выбрать t1, t2, t3. Эти результаты проверки накопительное разрешение внедряются в записи TokenAccessResult и вставляются в хранилища кэша TokenAndPermUserStore с Идентификатором 65535. Если же пользователь использует или выполняет в этом запросе несколько раз, SQL Server повторно использует запись кэша TokenAccessResult один раз.

После этого хранилища кэша растет, увеличивается время для поиска для повторного использования существующих записей. Таким образом, чтобы только один поток может выполнять поиск осуществляется доступ к кэшу. Это в конечном итоге вызывает запрос снижение производительности и возникает несколько ЦП.

Решение

Сведения о пакете обновления

Чтобы устранить эту проблему, получите последний пакет обновления для SQL Server 2005. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

913089 как получить последний пакет обновления для SQL Server 2005
Чтобы устранить эту проблему, Пакет обновления 2 для SQL Server 2005 изменяет поведение кэширования маркеров разрешение. По умолчанию запись кэша безопасности TokenAccessResult для нерегламентированных запросов кэшируются только при определенных нерегламентированный запрос выполняется снова.

Временное решение

Чтобы обойти эту проблему, используйте один или несколько из следующих методов:

  • Явно параметризовать нерегламентированных запросов.

    Примечания

    • Этот метод позволяет эффективно использовать нерегламентированные запросы и планов.

    • При использовании этого метода нет необходимости создать запись в TokenAccessResult каждый раз при выполнении нерегламентированного запроса вместе с другими параметрами.

    • С помощью этого метода размер кэша TokenAndPermUserStore остается в разумных пределов.

  • Включить нерегламентированные запросы в хранимых процедурах и использовать хранимые процедуры вместо непосредственного выполнения нерегламентированных запросов.

    Примечания

    • Планы выполнения остаются в кэше инструкции в хранимой процедуре.

    • Запись TokenAccessResult для каждой инструкции связан с записью плана выполнения.

    • До тех пор, пока план выполнения для этой процедуры остается хранится в кэше, каждое выполнение хранимой процедуры эффективно использует записи TokenAccessResult. Таким образом нет необходимости создавать новые записи TokenAccessResult.

  • Параметр базы данных FORCE_PARAMETERIZATION.

    Примечания

    • Этот метод позволяет эффективно использовать нерегламентированные запросы и планов.

    • При использовании этого метода нет необходимости создать запись в TokenAccessResult каждый раз при выполнении нерегламентированного запроса вместе с другими параметрами.

    • С помощью этого метода размер кэша TokenAndPermUserStore остается в разумных пределов.

  • Добавление имени входа, выполняющего самых разнообразных нерегламентированных запросов является членом группы sysadmin сервера.

    Примечания

    • TokenAccessResult записи создаются только для нерегламентированных запросов, при выполнении запроса, имя входа, которое не является членом группы sysadmin сервера.

    • Поскольку TokenAccessResult операции не были созданы, это сохраняет размер кэша TokenAndPermUserStore управляемый размер.

  • Очистите записи из кэша TokenAndPermUserStore.

    Примечания

    • Чтобы сделать это, выполните следующую команду:

      Инструкция DBCC FREESYSTEMCACHE (TokenAndPermUserStore)

    • В идеале попробуйте смотреть пороговое значение размера кэша TokenAndPermUserStore начала появляются проблемы.

    • Можно создавать задания агента SQL Server, который выполняет следующие действия:

      • Проверьте размер кэша TokenAndPermUserStore. Чтобы сделать это, выполните следующую команду:

        SELECT SUM(single_pages_kb + multi_pages_kb) AS    "CurrentSizeOfTokenCache(kb)" 
        FROM sys.dm_os_memory_clerks
        WHERE name = 'TokenAndPermUserStore'
      • Если размер кэша превышает пороговое значение, которое можно наблюдать, выполните следующую команду:

        DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Ссылки

Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

ИСПРАВИТЬ 933564 : в SQL Server 2005 возникает постепенное увеличение потребления памяти для хранения кэша USERSTORE_TOKENPERM

Как настроить квоты хранилища кэша TokenAndPermUserStore в Пакет обновления 3 для SQL Server 2005 959823

Настройки кеша запросов Shard | Руководство по Elasticsearch [7.13]

Настройки кеша запросов осколковправить

Когда поисковый запрос выполняется по индексу или по множеству индексов, каждый вовлеченный шард выполняет поиск локально и возвращает его локальные результаты в координирующий узел , который объединяет эти результаты на уровне сегментов в «Глобальный» набор результатов.

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

По умолчанию кеш запросов будет кэшировать только результаты поисковых запросов. где size = 0 , поэтому он не будет кэшировать совпадений , но он будет кэшировать обращений. всего , агрегации и предложения.

Большинство запросов, которые используют сейчас (см. Математика дат), не могут быть кэшированы.

Скриптовые запросы, использующие недетерминированные вызовы API, такие как Math.random () или new Date () не кэшируются.

Аннулирование кеша

Кэш умный — он выполняет те же обещания почти в реальном времени , что и некэшированные поиск.

Кешированные результаты автоматически становятся недействительными всякий раз, когда сегмент обновляется до забирать изменения в документы или при обновлении сопоставления. В другом слова, вы всегда будете получать из кеша те же результаты, что и для некэшированный поисковый запрос.

Чем дольше интервал обновления, тем дольше будут оставаться кешированные записи. действует даже при наличии изменений в документах. Если кеш заполнен, Ключи кеша, использовавшиеся недавно, будут удалены.

Срок действия кеша можно истечь вручную с помощью clear-cache API:

 POST / мой-индекс-000001, мой-индекс-000002 / _cache / clear? Request = true 
Включение и отключение кешированияправить

Кэш включен по умолчанию, но может быть отключен при создании нового индекс следующий:

 PUT / my-index-000001
{
  "настройки": {
    "индекс.requests.cache.enable ": ложь
  }
} 

Он также может быть включен или отключен динамически для существующего индекса с помощью update-settings API:

 PUT / my-index-000001 / _settings
{"index.requests.cache.enable": true} 
Включение и отключение кеширования по запросу

Параметр request_cache строки запроса может использоваться для включения или отключения кэширование на основе на запрос . Если установлено, оно отменяет настройку уровня индекса:

 GET / мой-индекс-000001 / _search? Request_cache = true
{
  "размер": 0,
  "aggs": {
    "popular_colors": {
      "термины": {
        "поле": "цвета"
      }
    }
  }
} 

Запросы, где размер больше 0, не будут кэшироваться, даже если кеш запроса включен в настройках индекса.Чтобы кэшировать эти запросы, вам нужно будет использовать параметр строки запроса подробно описан здесь.

Ключ кеширования

В качестве ключа кеша используется все тело JSON. Это означает, что если JSON изменения — например, если ключи выводятся в другом порядке — тогда ключ кеша не будет распознан.

Большинство библиотек JSON поддерживают канонический режим , который гарантирует, что JSON ключи всегда выдаются в одном и том же порядке. Этот канонический режим можно использовать в приложение, чтобы гарантировать, что запрос всегда сериализуется одинаково.

Настройки кэшаправить

Кэш управляется на уровне узла и имеет максимальный размер по умолчанию 1% из кучи. Это можно изменить в файле config / elasticsearch.yml с помощью:

 index.requests.cache.size: 2% 

Кроме того, вы можете использовать параметр indices.requests.cache.expire , чтобы указать TTL. для кешированных результатов, но не должно быть причин для этого. Помни это устаревшие результаты автоматически становятся недействительными при обновлении индекса.Этот настройка предназначена только для полноты картины.

Мониторинг использования кэшаправить

Размер кеша (в байтах) и количество выселений можно посмотреть по индексу, с индексами-статистикой API:

 GET / _stats / request_cache? Человек 

или по узлам с node -stats API:

 GET / _nodes / stats / index / request_cache? Человек 

Полный обзор кешей Elasticsearch с пояснениями по размеру


В дополнение к чтению этого руководства мы рекомендуем вам выполнить проверку работоспособности Elasticsearch.Он обнаружит проблемы и улучшит производительность Elasticsearch, проанализировав размеры сегментов, пулы потоков, память, снимки, водяные знаки на диске и многое другое. Проверка Elasticsearch бесплатна и не требует установки.

Обзор

Elasticsearch использует три типа кэшей для повышения эффективности работы.

  • Кэш запросов узла
  • Кэш данных осколков
  • Кэш данных поля

Как они работают

Кэш запросов узла поддерживает результаты запросов, используемых в контексте фильтра.Результаты выселены на основании наименее использованного недавно.

Кэш данных Shard хранит результаты часто используемых запросов, у которых размер = 0, особенно результаты агрегирования. Этот кеш особенно актуален для случаев использования журналов, когда данные не обновляются по старым индексам, а регулярные агрегаты могут храниться в кеше для повторного использования.

Кэш данных поля используется для сортировки и агрегирования. Чтобы эти операции выполнялись быстро, Elasticsearch загружает эти значения в память.

Примеры

Elasticsearch обычно управляет кешем «за кулисами», без каких-либо специальных настроек. Однако можно отслеживать и ограничивать объем памяти, используемый на каждом узле для данного типа кеша, помещая в elasticsearch.yml следующее:

 indices.queries.cache.size: 10%

indices.fielddata.cache.size: 30% 

Обратите внимание, что приведенные выше значения фактически являются значениями по умолчанию, и нет необходимости устанавливать их специально.Значения по умолчанию подходят для большинства случаев использования, и их следует редко изменять.
Вы можете отслеживать использование кешей на каждом узле следующим образом:

 GET / _nodes / stats / index / fielddata

ПОЛУЧИТЬ / _nodes / stats / index / query_cache

GET / _nodes / stats / index / request_cache 

Примечания и полезные сведения

Создавайте запросы с помощью повторно используемых фильтров. Есть определенные части вашего запроса, которые являются хорошими кандидатами для повторного использования в большом количестве запросов, и вы должны разрабатывать свои запросы с учетом этого.Все, что не нужно оценивать, должно быть помещено в раздел фильтра запроса типа bool. Например, временные диапазоны, селекторы языка или предложения, исключающие неактивные документы, скорее всего, будут исключены в большом количестве запросов и должны быть включены в фильтрующие части запроса, чтобы их можно было кэшировать и повторно использовать.

В особенности позаботьтесь о временных фильтрах. «Сейчас-15м» нельзя использовать повторно, потому что «сейчас» будет постоянно меняться по мере продвижения временного окна. С другой стороны, «now-15 / m» округляется до ближайшей минуты и может быть повторно использовано (через кеш) в течение 60 секунд перед переходом на следующую минуту.

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

 Результаты POST / _search
{
  "запрос": {
"bool": {
  "должен": [
    {
      "матч": {
        "сообщение": {
          "запрос": "брексит"
        }
      }
    }
  ],
  "фильтр": [
    {
      "диапазон": {
        "@timestamp": {
          "gte": "now-10d / d"
          }
      }
    },
    {
      "срок": {
        "lang.keyword ": {
          "значение": "ru",
          «буст»: 1
        }
      }
    }
  ]
}
  }
} 

Ограничьте использование данных поля. Будьте осторожны при использовании fielddata = true в вашем сопоставлении, где количество терминов приведет к высокой мощности элементов. Если вы должны использовать fielddata = true, вы также можете уменьшить требования к кешу fielddata, ограничив требования к fielddata для данного индекса с помощью фильтра частоты данных поля.

 Результаты POST / _search
{
  "запрос": {
"bool": {
  "должен": [
    {
      "матч": {
        "сообщение": {
          "запрос": "брексит"
        }
      }
    }
  ],
  "фильтр": [
    {
      "диапазон": {
        "@timestamp": {
          "gte": "now-10d / d"
          }
      }
    },
    {
      "срок": {
        "lang.keyword ": {
          "значение": "ru",
          «буст»: 1
        }
      }
    }
  ]
}
  }
} 

Ошибки журнала, связанные с этой концепцией ES

Request.cache — веб-API | MDN

Свойство cache только для чтения интерфейса Request содержит режим кэширования запроса. Он контролирует, как запрос будет взаимодействовать с HTTP-кешем браузера.

  var currentCacheMode = запрос.кеш;  

Значение

Значение RequestCache . Доступные значения:

  • по умолчанию — браузер ищет соответствующий запрос в своем HTTP-кеше.
    • Если есть совпадение и оно свежее, оно будет возвращено из кеша.
    • Если есть совпадение, но оно устарело, браузер сделает условный запрос удаленному серверу. Если сервер указывает, что ресурс не изменился, он будет возвращен из кеша.В противном случае ресурс будет загружен с сервера и кеш будет обновлен.
    • Если совпадений нет, браузер сделает обычный запрос и обновит кеш загруженным ресурсом.
  • no-store — Браузер извлекает ресурс с удаленного сервера без предварительного просмотра кеша, и не будет обновлять кеш загруженным ресурсом.
  • reload — Браузер извлекает ресурс с удаленного сервера, не заглядывая сначала в кеш, , но затем обновляет кеш загруженным ресурсом.
  • no-cache — браузер ищет соответствующий запрос в своем HTTP-кеше.
    • Если есть совпадение, свежее или устаревшее, браузер сделает условный запрос к удаленному серверу. Если сервер указывает, что ресурс не изменился, он будет возвращен из кеша. В противном случае ресурс будет загружен с сервера и кеш будет обновлен.
    • Если совпадений нет, браузер сделает обычный запрос и обновит кеш загруженным ресурсом.
  • force-cache — браузер ищет соответствующий запрос в своем HTTP-кеше.
    • Если есть совпадение, свежее или устаревшее , оно будет возвращено из кеша.
    • Если совпадений нет, браузер сделает обычный запрос и обновит кеш загруженным ресурсом.
  • only-if-cached — браузер ищет соответствующий запрос в своем HTTP-кеше.
    • Если есть совпадение, свежее или устаревшее , оно будет возвращено из кеша.
    • Если совпадений нет, браузер ответит статусом тайм-аута 504 Gateway.
    Режим «только при кэшировании» можно использовать только в том случае, если режим запроса «тот же источник» . Кэшированные перенаправления будут выполняться, если свойство перенаправления запроса имеет значение «следовать» и перенаправления не нарушают режим «одинакового происхождения» .
 

fetch ("some.json", {cache: "no-store"})
  .then (функция (ответ) {});



fetch ("некоторые.json ", {cache:" reload "})
  .then (функция (ответ) {});






fetch ("some.json", {cache: "no-cache"})
  .then (функция (ответ) {});



fetch ("some.json", {cache: "force-cache"})
  .then (функция (ответ) {});






let controller = new AbortController ();
fetch ("some.json", {cache: "only-if-cached", mode: "same-origin", signal: controller.signal})
  .catch (e => e instanceof TypeError && e.message === "Не удалось получить"?
    ({status: 504}):
    Promise.reject (e))
  .then (res => {
    если (рез.status === 504) {
      controller.abort ()
      контроллер = новый AbortController ();
      return fetch ("some.json", {cache: "force-cache", mode: "same-origin", signal: controller.signal})
    }
    const date = res.headers.get ("date"), dt = date? новая дата (дата) .getTime (): 0
    if (dt <(Date.now () - 86400000)) {
      
      controller.abort ()
      контроллер = новый AbortController ();
      return fetch ("some.json", {cache: "reload", mode: "same-origin", signal: controller.signal})
    }

    
    если (dt <(Дата.сейчас () - 300000))
      fetch ("some.json", {cache: "no-cache", mode: "same-origin"})
    вернуть res
  })
  .then (функция (ответ) {})
  .catch (ошибка => {});  

Таблицы BCD загружаются только в браузере

Включение кэширования API для повышения скорости отклика

Вы можете включить кэширование API в Amazon API Gateway, чтобы кэшировать ответы конечной точки. С участием кэширование, вы можете уменьшить количество обращений к вашей конечной точке, а также улучшить в задержка запросов к вашему API.

Когда вы включаете кеширование для этапа, API Gateway кэширует ответы от вашей конечной точки. для указанный период времени жизни (TTL) в секундах. Затем API-шлюз отвечает на запрос от поиск ответа конечной точки из кеша вместо того, чтобы делать запрос на ваш конечная точка.Значение TTL по умолчанию для кеширования API составляет 300 секунд. Максимальное значение TTL является 3600 секунд. TTL = 0 означает, что кеширование отключено.

Максимальный размер ответа, который можно кэшировать, составляет 1048576 байт. Шифрование данных кеша может увеличить размер ответа при его кэшировании.

Это услуга, отвечающая требованиям HIPAA.Дополнительные сведения об AWS, медицинском страховании в США. Закон о переносимости и подотчетности 1996 г. (HIPAA) и использование сервисов AWS для обработки, хранить и передавать защищенную медицинскую информацию (PHI), см. Обзор HIPAA.

Когда вы включаете кеширование для этапа, только методы GET имеют кеширование включен по умолчанию.Это помогает обеспечить безопасность и доступность вашего API. Ты может включить кеширование для других методов, переопределив метод настройки.

Кэширование оплачивается почасово и не соответствует уровню бесплатного пользования AWS.

Включение кэширования Amazon API Gateway

В API Gateway можно включить кеширование для указанного этапа.

При включении кэширования необходимо выбрать емкость кеша. В общем, больший Емкость дает лучшую производительность, но также стоит дороже.

API Gateway включает кэширование путем создания выделенного экземпляра кеша. Этот процесс может взять до 4 минут.

API Gateway изменяет емкость кэширования, удаляя существующий экземпляр кеша и создавая а новый с доработанной емкостью.Все существующие кэшированные данные удаляются.

Емкость кэша влияет на ЦП, память и пропускную способность сети экземпляра кэша. В результате Емкость кеша может повлиять на производительность вашего кеша.

API Gateway рекомендует запустить 10-минутный нагрузочный тест, чтобы убедиться, что ваш кеш емкость подходит для ваша рабочая нагрузка. Убедитесь, что трафик во время нагрузочного теста отражает производственный трафик. Например, включить рампу вверх, постоянный трафик и скачки трафика.Нагрузочный тест должен включать ответы, которые может быть подан из cache, а также уникальные ответы, которые добавляют элементы в кеш. Следите за задержкой, 4xx, 5xx, попадание в кеш и метрики промаха кеша во время нагрузочного теста. Отрегулируйте емкость кеша по мере необходимости на основе по этим показателям.

В консоли API Gateway вы настраиваете кеширование на вкладке Settings именованного Stage Editor .

Чтобы настроить кеширование API для данного этапа:

  1. Перейдите в консоль API Gateway.

  2. Выберите API.

  3. Выберите Этапы .

  4. В списке Этапы для API выберите этап.

  5. Выберите вкладку Настройки .

  6. Выберите Включить кеш API .

  7. Дождитесь завершения создания кэша.

Создание или удаление кэша занимает около 4 минут для завершения API Gateway.При создании кэша значение Cache status изменяется с CREATE_IN_PROGRESS с по ДОСТУПНО . При удалении кеша завершено, значение Cache status изменится с DELETE_IN_PROGRESS в пустую строку.

Когда вы включаете кэширование в настройках кэша этапа , только GET Методы кэшируются.Для обеспечения безопасности и доступности вашего API, мы рекомендуем не изменять этот параметр. Однако вы можете включить кеширование для других методов путем переопределения настроек метода.

Если вы хотите проверить, работает ли кеширование должным образом, у вас есть два общие настройки:

Не следует использовать заголовок X-Cache из ответа CloudFront на определить, обслуживается ли ваш API из экземпляра кеша API Gateway.

Переопределить кэширование на уровне этапа шлюза API для кэширования методов

Вы можете переопределить настройки кеширования на уровне стадии, включив или отключив кеширование для конкретный метод.Увеличивая или уменьшая период TTL; или включив шифрование на или выключено для кешированных ответов.

Если вы ожидаете, что метод, который вы кэшируете, получит конфиденциальные данные в его ответы, в Cache Settings , выберите Encrypt cache данные .

Для настройки кеширования API для отдельных методов с помощью консоли:

  1. Войдите в консоль API Gateway по адресу https://console.aws.amazon.com/apigateway.

  2. Перейдите в консоль API Gateway.

  3. Выберите API.

  4. Выберите Этапы .

  5. В списке Этапы для API разверните этап и выберите метод в API.

  6. Выберите Переопределение для этого метода в Настройки .

  7. В области Cache Settings вы можете установить или очистить Включите кэш метода или настройте любой другой параметры.(Этот раздел отображается только в том случае, если кэширование на уровне стадии включено.)

Использовать метод или параметры интеграции в качестве ключей кеширования для индексации кэшированного ответы

Если кэшированный метод или интеграция имеет параметры, которые могут принимать форму настраиваемых заголовки, пути URL или строки запроса, вы можете использовать некоторые или все параметры для форма ключи кеша.API Gateway может кэшировать ответы метода в зависимости от параметра значения использовал.

Ключи кэша необходимы при настройке кеширования ресурса.

Например, предположим, что у вас есть запрос в следующем формате:

 
ПОЛУЧИТЬ / пользователи? Type =... HTTP / 1.1
host: example.com
...
          

В этом запросе тип может принимать значение admin или обычный . Если вы включите тип параметр как часть ключ кеширования, ответы от GET / users? type = admin кешируются отдельно из тех, что из GET / users? type = normal .

Если метод или запрос интеграции принимает более одного параметра, вы можете выбрать к включить некоторые или все параметры для создания ключа кэша. Например, вы можете включить в ключ кеша только параметр типа для следующего запроса, сделано в указанном порядке в течение периода TTL:

 
GET / users? Type = admin & Department = A HTTP / 1.1
host: example.com
...
          

Ответ на этот запрос кэшируется и используется для обслуживания следующего запроса:

 
GET / users? Type = admin & Department = B HTTP / 1.1
host: example.com
...
          

Чтобы включить метод или параметр запроса интеграции как часть ключа кэша в В консоли API Gateway выберите Caching после добавления параметра.

Очистить кеш этапа API в API-шлюзе

Когда кеширование API включено, вы можете очистить весь кеш этапа API, чтобы гарантировать клиенты вашего API получают самые последние ответы от ваших конечных точек интеграции.

Чтобы очистить кеш этапа API, вы можете выбрать Очистить всю cache в разделе Cache Settings в Вкладка «Настройки» в редакторе сцены консоли API Gateway. В операция очистки кеша занимает пару минут, после чего состояние кеша В НАЛИЧИИ сразу после промывки.

После очистки кеша ответы обслуживаются конечной точкой интеграции. пока кеш снова не будет создан. За этот период количество отправленных запросов до конечной точки интеграции может увеличиться.Это может временно увеличить общий задержка вашего API.

Сделать недействительной запись кэша шлюза API

Клиент вашего API может аннулировать существующую запись кэша и перезагрузить ее из конечная точка интеграции для индивидуальных запросов.Клиент должен отправить запрос, который содержит заголовок Cache-Control: max-age = 0 . Клиент получает ответ напрямую от конечной точки интеграции, а не из кеша, при условии, что в клиент имеет на это право. Это заменяет существующую запись кэша новым ответ, полученный от конечной точки интеграции.

Чтобы предоставить разрешение для клиента, прикрепите политику следующего формата к IAM роль исполнения для пользователя.

 
{
  «Версия»: «2012-10-17»,
  "Заявление": [
    {
      «Эффект»: «Разрешить»,
      "Действие": [
        "execute-api: InvalidateCache"
      ],
      «Ресурс»: [
        "arn: aws: execute-api:  регион :  идентификатор-учетной записи :  идентификатор-API / имя-этапа  / GET /  указатель-пути-ресурса "
      ]
    }
  ]
}
          

Эта политика позволяет службе выполнения шлюза API аннулировать кеш для Запросы на указанном ресурсе (или ресурсах).Чтобы указать группу целевых ресурсов, использовать подстановочный знак (*) для account-id , api-id и других записей в значении ARN ресурса . Для получения дополнительной информации о том, как установить разрешения для службы выполнения шлюза API, см. раздел Управление доступом к API с разрешениями IAM.

Если вы не применяете политику InvalidateCache (или выберите Требовать авторизацию флажок в консоли) любой клиент может сделать недействительным кеш API.Если большинство или все клиенты аннулируют кеш API, это может значительно увеличить задержку вашего API.

При наличии политики кэширование включено и требуется авторизация. Ты может контролировать обработку неавторизованных запросов, выбрав опцию из Обработка неавторизованных запросов в консоли API Gateway.

Три варианта приводят к следующему поведению:

  • Ошибка запроса с кодом состояния 403 : возвращает 403 Несанкционированный ответ.

    Чтобы установить этот параметр с помощью API, используйте FAIL_WITH_403 .

  • Игнорировать заголовок управления кешем; Добавить предупреждение в ответ заголовок : обработать запрос и добавить заголовок предупреждения в отклик.

    Чтобы установить эту опцию с помощью API, используйте SUCCEED_WITH_RESPONSE_HEADER .

  • Игнорировать заголовок управления кешем : обрабатывать запрос и не добавить заголовок предупреждения в ответ.

    Чтобы установить эту опцию с помощью API, используйте SUCCEED_WITHOUT_RESPONSE_HEADER .

MySQL :: MySQL 5.6 Справочное руководство :: 8.10.3.3 Конфигурация кэша запросов

8.10.3.3 Конфигурация кэша запросов

Сервер have_query_cache системная переменная указывает, является ли кеш запроса имеется в наличии:

  mysql> ПОКАЗАТЬ ПЕРЕМЕННЫЕ КАК 'have_query_cache';
+ ------------------ + ------- +
| Имя_переменной | Значение |
+ ------------------ + ------- +
| have_query_cache | ДА |
+ ------------------ + ------- +  

При использовании стандартного двоичного файла MySQL это значение всегда ДА , даже если кеширование запросов отключено.

Несколько других системных переменных управляют работой кеша запросов. Их можно установить в файле параметров или в командной строке, когда запуск mysqld . Система кеширования запросов все переменные имеют имена, начинающиеся с query_cache_ . Они кратко описаны в Раздел 5.1.7, «Системные переменные сервера», с дополнительными информация о конфигурации приведена здесь.

Чтобы установить размер кеша запросов, установите query_cache_size система Переменная.Установка его в 0 отключает кеш запросов, как и установка query_cache_type = 0 . По умолчанию кеш запросов отключен. Это достигается используя размер по умолчанию 1M, со значением по умолчанию для query_cache_type из 0.

Чтобы значительно снизить накладные расходы, запустите сервер с query_cache_type = 0 , если вы это сделаете не намереваются использовать кеш запросов.

Примечание

При использовании мастера настройки Windows для установки или настроить MySQL, значение по умолчанию для query_cache_size - это настраивается автоматически для вас на основе различных доступные типы конфигурации.При использовании Windows Мастер настройки, может быть включен кеш запросов (что есть, установлено ненулевое значение) из-за выбранного конфигурация. Кешем запросов также управляет установка query_cache_type переменная. Проверьте значения этих переменных, как установлено в вашем my.ini файл после конфигурации состоялось.

Когда вы устанавливаете query_cache_size к ненулевому значению, имейте в виду, что для кеша запросов требуется минимальный размер около 40 КБ для размещения его структур.(В точный размер зависит от архитектуры системы.) Если вы установите значение слишком мало, вы получите предупреждение, как в этом примере:

  mysql> УСТАНОВИТЬ ГЛОБАЛЬНЫЙ query_cache_size = 40000;
Запрос выполнен, затронуты 0 строк, 1 предупреждение (0,00 сек)

mysql> ПОКАЗАТЬ ПРЕДУПРЕЖДЕНИЯ \ G
*************************** 1. строка ******************** *******
  Уровень: Предупреждение
   Код объявления: 1282
Сообщение: Кэш запросов не смог установить размер 39936;
         размер кеша нового запроса равен 0

mysql> УСТАНОВИТЬ ГЛОБАЛЬНЫЙ query_cache_size = 41984;
Запрос выполнен, затронуты 0 строк (0.00 сек)

mysql> ПОКАЗАТЬ ПЕРЕМЕННЫЕ КАК 'query_cache_size';
+ ------------------ + ------- +
| Имя_переменной | Значение |
+ ------------------ + ------- +
| query_cache_size | 41984 |
+ ------------------ + ------- +  

Чтобы кеш запросов действительно мог хранить любой запрос результатов, его размер необходимо установить больше:

  mysql> УСТАНОВИТЬ ГЛОБАЛЬНЫЙ query_cache_size = 1000000;
Запрос в порядке, затронуто 0 строк (0,04 сек)

mysql> ПОКАЗАТЬ ПЕРЕМЕННЫЕ КАК 'query_cache_size';
+ ------------------ + -------- +
| Имя_переменной | Значение |
+ ------------------ + -------- +
| query_cache_size | 999424 |
+ ------------------ + -------- +
1 ряд в комплекте (0.00 сек)  

Значение query_cache_size равно выровнен по ближайшему 1024-байтовому блоку. Сообщенное значение может следовательно, отличаться от присвоенного вами значения.

Если размер кеша запросов больше 0, query_cache_type переменная влияет на то, как это работает. Этой переменной можно присвоить значение следующие значения:

  • Значение 0 или ВЫКЛ предотвращает кеширование или получение кешированных результатов.

  • Значение 1 или ON включает кеширование, кроме тех операторов, которые начинаются с ВЫБЕРИТЕ SQL_NO_CACHE .

  • Значение 2 или DEMAND вызывает кеширование только тех операторы, начинающиеся с SELECT SQL_CACHE .

Если query_cache_size равно 0, вы также следует установить query_cache_type переменная для 0.В этом случае сервер не получает кеш запросов. мьютекс вообще, а это значит, что кеш запросов нельзя включен во время выполнения и снижает накладные расходы на запрос исполнение.

Установка GLOBAL query_cache_type значение определяет поведение кеша запросов для всех клиентов, которые подключаются после внесения изменений. Отдельные клиенты могут управлять кешем поведение для их собственного соединения, установив СЕССИЯ query_cache_type значение.Для Например, клиент может отключить использование кеша запросов для своих собственные запросы вроде этого:

  mysql> УСТАНОВИТЬ СЕССИЮ query_cache_type = OFF;  

Если вы установите query_cache_type при запуске сервера (а не во время выполнения с НАБОР оператор), разрешены только числовые значения.

Для управления максимальным размером отдельных результатов запроса, которые можно кэшировать, установите query_cache_limit система Переменная.Значение по умолчанию - 1 МБ.

Будьте осторожны, чтобы не установить слишком большой размер кеша. Из-за необходимость в потоках для блокировки кеша во время обновлений, вы можете см. проблемы конкуренции блокировок с очень большим кешем.

Примечание

Вы можете установить максимальный размер, который может быть указан для кеш запросов во время выполнения с НАБОР заявление с помощью --maximum-query_cache_size = 32M параметр в командной строке или в файле конфигурации.

Когда запрос должен быть кэширован, его результат (данные, отправленные в client) хранится в кэше запросов во время получения результата. Поэтому данные обычно не обрабатываются одним большим блоком. Кэш запросов выделяет блоки для хранения этих данных на спроса, поэтому при заполнении одного блока выделяется новый блок. Поскольку операция выделения памяти является дорогостоящей (по времени), кеш запросов выделяет блоки с минимальным размером, заданным query_cache_min_res_unit системная переменная.Когда запрос выполняется, последний результат блок обрезается до фактического размера данных, так что неиспользуемая память освобожден. В зависимости от типов запросов ваш сервер выполняется, вам может быть полезно настроить значение query_cache_min_res_unit :

  • Значение по умолчанию query_cache_min_res_unit составляет 4 КБ. Этого должно хватить для большинства случаев.

  • Если у вас много запросов с небольшими результатами, размер блока по умолчанию может привести к фрагментации памяти, так как обозначается большим количеством свободных блоков.Фрагментация может заставить кеш запросов отсекать (удалять) запросы из кеш из-за нехватки памяти. В этом случае уменьшите значение query_cache_min_res_unit . Количество свободных блоков и запросов, удаленных из-за обрезки даны значениями Qcache_free_blocks и Qcache_lowmem_prunes переменные состояния.

  • Если большинство ваших запросов дают большие результаты (проверьте Qcache_total_blocks и Qcache_queries_in_cache статусные переменные), вы можете повысить производительность, увеличение query_cache_min_res_unit .Однако будьте осторожны, чтобы не сделать его слишком большим (см. предыдущий пункт).

Расчет используемой памяти кеш-памяти

некорректен, что приводит к тому, что старый gc не останавливается. · Проблема № 26938 · elastic / elasticsearch · Вычисление используемой памяти кэша запросов GitHub

неверно, что приводит к тому, что старый gc не останавливается. · Проблема № 26938 · elastic / elasticsearch · GitHub. Правопреемники

Комментарии

jpountz добавил коммит в jpountz / elasticsearch это упомянуло Эта проблема 23 октября 2017 г.
 Использование памяти запросами не может быть правильно учтено, что может быть проблемой при
большие запросы кэшируются, поскольку фактическое использование памяти будет намного выше, чем
что думает кеш.Эту проблему очень сложно, если вообще возможно, исправить, так как
обходной путь Я хотел бы уменьшить максимальное количество кешированных запросов, чтобы
что эта проблема с меньшей вероятностью вызовет проблемы на практике.

Для справки, эта проблема чаще возникает в средах, где есть
небольшие осколки или не выделяйте много памяти для JVM.

Закрывается на резинке # 26938 
. jpountz добавил коммит это упомянуло Эта проблема 23 октября 2017 г.
 Использование памяти запросами не может быть правильно учтено, что может быть проблемой при
большие запросы кэшируются, поскольку фактическое использование памяти будет намного выше, чем
что думает кеш.Эту проблему очень сложно, если вообще возможно, исправить, так как
обходной путь Я хотел бы уменьшить максимальное количество кешированных запросов, чтобы
что эта проблема с меньшей вероятностью вызовет проблемы на практике.

Для справки, эта проблема чаще возникает в средах, где есть
небольшие осколки или не выделяйте много памяти для JVM.

Закрывает # 26938 
jpountz добавил коммит это упомянуло Эта проблема 23 октября 2017 г.
 Использование памяти запросами не может быть правильно учтено, что может быть проблемой при
большие запросы кэшируются, поскольку фактическое использование памяти будет намного выше, чем
что думает кеш.Эту проблему очень сложно, если вообще возможно, исправить, так как
обходной путь Я хотел бы уменьшить максимальное количество кешированных запросов, чтобы
что эта проблема с меньшей вероятностью вызовет проблемы на практике.

Для справки, эта проблема чаще возникает в средах, где есть
небольшие осколки или не выделяйте много памяти для JVM.

Закрывает # 26938 
jpountz добавил коммит это упомянуло Эта проблема 23 октября 2017 г.
 Использование памяти запросами не может быть правильно учтено, что может быть проблемой при
большие запросы кэшируются, поскольку фактическое использование памяти будет намного выше, чем
что думает кеш.Эту проблему очень сложно, если вообще возможно, исправить, так как
обходной путь Я хотел бы уменьшить максимальное количество кешированных запросов, чтобы
что эта проблема с меньшей вероятностью вызовет проблемы на практике.

Для справки, эта проблема чаще возникает в средах, где есть
небольшие осколки или не выделяйте много памяти для JVM.

Закрывает # 26938 
jpountz добавил коммит это упомянуло Эта проблема 23 октября 2017 г.
 Использование памяти запросами не может быть правильно учтено, что может быть проблемой при
большие запросы кэшируются, поскольку фактическое использование памяти будет намного выше, чем
что думает кеш.Эту проблему очень сложно, если вообще возможно, исправить, так как
обходной путь Я хотел бы уменьшить максимальное количество кешированных запросов, чтобы
что эта проблема с меньшей вероятностью вызовет проблемы на практике.

Для справки, эта проблема чаще возникает в средах, где есть
небольшие осколки или не выделяйте много памяти для JVM.

Закрывает # 26938 
Вы не можете выполнить это действие в настоящее время.Вы вошли в систему с другой вкладкой или окном. Перезагрузите, чтобы обновить сеанс. Вы вышли из системы на другой вкладке или в другом окне. Перезагрузите, чтобы обновить сеанс. Кэш-фреймворк

Django | Документация Django

Фундаментальный компромисс в динамических веб-сайтах заключается в том, что они динамичны. Каждый когда пользователь запрашивает страницу, веб-сервер производит всевозможные вычисления - от запросов к базе данных до рендеринга шаблонов и бизнес-логики - для создания страницу, которую видит посетитель вашего сайта.Это намного дороже, от перспектива обработки накладных расходов, чем ваш стандарт устройство сервера чтения файла вне файловой системы.

Для большинства веб-приложений эти накладные расходы не имеют большого значения. Большинство веб-сайтов приложения - это не washtonpost.com или slashdot.org ; они маленькие- на сайты среднего размера с средней посещаемостью. Но для среднего и высокого трафика сайтов, важно максимально сократить накладные расходы.

Вот тут и пригодится кеширование.

Кэшировать что-либо - значит сохранить результат дорогостоящего вычисления, чтобы в следующий раз выполнять расчет не нужно.Вот какой-то псевдокод объясняя, как это будет работать для динамически генерируемой веб-страницы:

 с заданным URL-адресом, попробуйте найти эту страницу в кеше.
если страница находится в кеше:
    вернуть кешированную страницу
еще:
    создать страницу
    сохранить сгенерированную страницу в кеше (в следующий раз)
    вернуть сгенерированную страницу
 

Django поставляется с надежной системой кеширования, которая позволяет сохранять динамические страницы, чтобы их не нужно рассчитывать для каждого запроса. Для удобства Django предлагает разные уровни детализации кеша: вы можете кэшировать вывод определенные виды, вы можете кэшировать только те части, которые сложно создать, или вы можете кэшировать весь свой сайт.

Django также хорошо работает с «нисходящими» кэшами, такими как Squid и кешами на основе браузера. Это типы кешей, которые вы не контролируете напрямую, но которым вы можете давать подсказки (через заголовки HTTP) о том, какие части вашего сайта и как следует кэшировать.

Настройка кеша¶

Система кэширования требует небольшой настройки. А именно, вы должны это сказать где должны находиться ваши кэшированные данные - будь то в базе данных или в файловой системе или прямо в памяти.Это важное решение, которое влияет на ваш кеш представление; да, некоторые типы кешей быстрее других.

Ваши предпочтения кеша находятся в настройке CACHES в вашем файл настроек. Вот объяснение всех доступных значений для КЭШИ .

Memcached¶

Самый быстрый и эффективный тип кеша, изначально поддерживаемый Django, Memcached - полностью основанный на памяти кэш-сервер, первоначально разработанный справляться с большими нагрузками на LiveJournal.com, а затем с открытым исходным кодом Danga Interactive. Он используется такими сайтами, как Facebook и Wikipedia, чтобы уменьшить доступ к базе данных и значительно повысить производительность сайта.

Memcached работает как демон, и ему выделяется определенный объем оперативной памяти. Все это действительно предоставляет быстрый интерфейс для добавления, извлечения и удаления данных в кеш. Все данные хранятся непосредственно в памяти, поэтому нет накладных расходов на использование базы данных или файловой системы.

После установки самого Memcached вам потребуется установить Memcached. привязка.Доступно несколько привязок Python Memcached; в два, поддерживаемые Django, - это pylibmc и pymemcache.

Для использования Memcached с Django:

  • Установить BACKEND на django.core.cache.backends.memcached.PyMemcacheCache или django.core.cache.backends.memcached.PyLibMCCache (в зависимости от вашего выбрана привязка memcached)
  • Установить LOCATION to ip: port values, где ip - это IP-адрес демона Memcached, а порт - это порт, на котором запущен Memcached, или значение unix: path , где путь - это путь к файлу сокета Memcached Unix.

В этом примере Memcached работает на локальном (127.0.0.1) порту 11211, используя привязка pymemcache :

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        "МЕСТОПОЛОЖЕНИЕ": "127.0.0.1:11211",
    }
}
 

В этом примере Memcached доступен через локальный файл сокета Unix. /tmp/memcached.sock с использованием привязки pymemcache :

 КЭШОВ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.memcached.PyMemcacheCache ',
        'МЕСТОПОЛОЖЕНИЕ': 'unix: /tmp/memcached.sock',
    }
}
 

Отличной особенностью Memcached является возможность совместного использования кеша несколько серверов. Это означает, что вы можете запускать демоны Memcached на нескольких машин, и программа будет рассматривать группу машин как одиночных cache, без необходимости дублировать значения кеша на каждой машине. Брать Преимущество этой функции, включение всех адресов серверов в МЕСТО , либо точка с запятой, либо запятая. строка с разделителями или в виде списка.

В этом примере кеш совместно используется экземплярами Memcached, работающими на IP. адрес 172.19.26.240 и 172.19.26.242, оба на порту 11211:

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'МЕСТО РАСПОЛОЖЕНИЯ': [
            '172.19.26.240:11211',
            '172.19.26.242:11211',
        ]
    }
}
 

В следующем примере кеш используется совместно с запущенными экземплярами Memcached. по IP-адресам 172.19.26.240 (порт 11211), 172.19.26.242 (порт 11212) и 172.19.26.244 (порт 11213):

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'МЕСТО РАСПОЛОЖЕНИЯ': [
            '172.19.26.240:11211',
            '172.19.26.242:11212',
            '172.19.26.244:11213',
        ]
    }
}
 

Последний пункт о Memcached заключается в том, что кэширование на основе памяти имеет Недостаток: поскольку кешированные данные хранятся в памяти, данные будут потеряно, если ваш сервер выйдет из строя.Очевидно, что память не предназначена для постоянных данных. хранилище, поэтому не полагайтесь на кеширование в памяти как на единственное хранилище данных. Без сомнения, нет бэкэндов кеширования Django следует использовать для постоянное хранилище - все они предназначены для решения проблемы кеширования, а не хранилище - но мы указываем на это здесь, потому что кэширование на основе памяти особенно временный.

Изменено в Django 3.2:

Добавлен бэкэнд PyMemcacheCache .

Не рекомендуется, начиная с версии 3.2: бэкэнд MemcachedCache устарел, поскольку python-memcached имеет некоторые проблемы и, похоже, не устранены. Используйте PyMemcacheCache или PyLibMCCache вместо этого.

Кэширование базы данных¶

Django может хранить свои кэшированные данные в вашей базе данных. Это лучше всего работает, если вы получил быстрый, хорошо индексируемый сервер базы данных.

Чтобы использовать таблицу базы данных в качестве серверной части кеша:

  • Установить BACKEND на джанго.core.cache.backends.db.DatabaseCache
  • Установите LOCATION на имя таблицы , имя таблица базы данных. Это имя может быть любым, если это действительное имя таблицы, которое еще не используется в вашей базе данных.

В этом примере имя таблицы кеша - my_cache_table :

 КЭШОВ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}
 

В отличие от других механизмов кэширования, кэш базы данных не поддерживает автоматическое удаление просроченных записей на уровне базы данных.Вместо этого просроченный кеш записи отбираются каждый раз, когда вызывается add () , set () или touch () .

Создание таблицы кеширования¶

Перед использованием кэша базы данных необходимо создать таблицу кэша с этим команда:

 python manage.py createcachetable
 

Это создает таблицу в вашей базе данных в правильном формате, Система кеширования баз данных Django ожидает. Название таблицы взято из МЕСТО .

Если вы используете несколько кешей базы данных, createcachetable создает по одной таблице для каждого кеша.

Если вы используете несколько баз данных, createcachetable соблюдает allow_migrate () метод маршрутизаторов вашей базы данных (см. Ниже).

Как и , перенесите , createcachetable не коснется существующего Таблица. Это только создаст недостающие таблицы.

Чтобы распечатать SQL, который будет запускаться, а не запускать его, используйте createcachetable --dry-run option.

Несколько баз данных¶

Если вы используете кэширование нескольких баз данных, вам также понадобится для настройки инструкций по маршрутизации для таблицы кэша вашей базы данных. Для В целях маршрутизации таблица кэша базы данных отображается как модель с именем CacheEntry в приложении с именем django_cache . Эта модель не будет отображаться в кеше моделей, но детали модели могут быть использованы для целей маршрутизации.

Например, следующий маршрутизатор будет направлять все чтение кеша. операций в cache_replica , а все операции записи в cache_primary .Таблица кеша будет синхронизироваться только на cache_primary :

 класс CacheRouter:
    "" "Маршрутизатор для управления всеми операциями с кешем базы данных" ""

    def db_for_read (сам, модель, ** подсказки):
        «Все операции чтения из кеша переходят в реплику»
        если model._meta.app_label == 'django_cache':
            вернуть 'cache_replica'
        return None

    def db_for_write (сам, модель, ** подсказки):
        «Все операции записи в кэш переходят в основной»
        если model._meta.app_label == 'django_cache':
            вернуть 'cache_primary'
        return None

    def allow_migrate (self, db, app_label, model_name = None, ** подсказки):
        "Устанавливать модель кеша только на основной"
        если app_label == 'django_cache':
            вернуть db == 'cache_primary'
        return None
 

Если вы не укажете направления маршрутизации для модели кэша базы данных, бэкэнд кеша будет использовать базу данных по умолчанию .

И если вы не используете серверную часть кеширования базы данных, вам не нужно беспокоиться о предоставление инструкций по маршрутизации для модели кэша базы данных.

Кэширование файловой системы¶

Файловый бэкэнд сериализует и сохраняет каждое значение кэша как отдельное файл. Чтобы использовать этот бэкэнд, установите BACKEND на "django.core.cache.backends.filebased.FileBasedCache" и МЕСТО в подходящий каталог. Например, для хранения кэшированных данных в / var / tmp / django_cache используйте этот параметр:

 КЭШОВ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.filebased.FileBasedCache ',
        'МЕСТОПОЛОЖЕНИЕ': '/ var / tmp / django_cache',
    }
}
 

Если вы работаете в Windows, укажите букву диска в начале пути, как это:

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'МЕСТОПОЛОЖЕНИЕ': 'c: / foo / bar',
    }
}
 

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

Убедитесь, что каталог, на который указывает этот параметр, существует и читаемый и доступный для записи, или что он может быть создан пользователем системы, под которым ваш веб-сервер работает. Продолжая приведенный выше пример, если ваш сервер работает как пользователь apache , убедитесь, что каталог / var / tmp / django_cache существует и доступен для чтения и записи пользователем apache или может быть создан с помощью пользователь apache .

Предупреждение

Когда кэш МЕСТО содержится в MEDIA_ROOT , STATIC_ROOT или STATICFILES_FINDERS , конфиденциальные данные могут быть раскрыты.

Злоумышленник, получивший доступ к файлу кеша, может не только фальсифицировать HTML. контент, которому будет доверять ваш сайт, но также удаленно выполнять произвольные code, поскольку данные сериализуются с использованием pickle .

Кэширование в локальной памяти¶

Это кэш по умолчанию, если другой не указан в вашем файле настроек. Если вам нужны преимущества скорости кэширования в памяти, но у вас нет возможности Для запуска Memcached рассмотрите бэкэнд кэша локальной памяти. Этот кеш на процесс (см. ниже) и потокобезопасный.Чтобы использовать его, установите BACKEND на "django.core.cache.backends.locmem.LocMemCache" . Для пример:

 КЭШОВ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.locmem.LocMemCache',
        "МЕСТО": "уникальная снежинка",
    }
}
 

Кэш-память МЕСТОПОЛОЖЕНИЕ используется для идентификации личности память хранит. Если у вас только один кеш locmem , вы можете опустить МЕСТО ; однако, если у вас более одного местного кеш памяти, вам нужно будет присвоить имя хотя бы одному из них в чтобы держать их отдельно.

Кэш использует стратегию отбраковки наименее недавно использовавшихся (LRU).

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

Dummy caching (для разработки) ¶

Наконец, Django поставляется с «фиктивным» кешем, который на самом деле не кеширует - он просто реализует интерфейс кеша, ничего не делая.

Это полезно, если у вас есть производственный сайт, который использует усиленное кэширование в различные места, кроме среды разработки / тестирования, в которой вы не хотите кэшировать и не хочу менять свой код на особый случай. К активируйте фиктивное кеширование, установите BACKEND вот так:

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
    }
}
 

Использование настраиваемого серверного модуля кеширования¶

В то время как Django включает в себя поддержку ряда серверных модулей кеширования прямо из коробки, иногда вы можете захотеть использовать настраиваемый бэкэнд кеширования.Чтобы использовать внешний бэкэнд кеширования с Django, используйте путь импорта Python в качестве BACKEND настройки CACHES , например:

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'path.to.backend',
    }
}
 

Если вы создаете собственный бэкэнд, вы можете использовать стандартные бэкэнды кеширования. в качестве эталонных реализаций. Вы найдете код в django / core / cache / backends / каталог исходного кода Django.

Примечание. Без веских причин, например, если хост не поддерживает их следует придерживаться бэкэндов кеширования, включенных в Django.Они есть были хорошо протестированы и хорошо задокументированы.

Аргументы кеша¶

Каждому бэкэнду кеширования можно дать дополнительные аргументы для управления кешированием. поведение. Эти аргументы предоставляются как дополнительные ключи в КЭШИ настройки. Допустимые аргументы:

  • TIMEOUT : Тайм-аут по умолчанию, в секунд, чтобы использовать для кеширования. По умолчанию этот аргумент равен 300 секунд (5 минут). Вы можете установить TIMEOUT на None , чтобы по умолчанию ключи кеширования никогда не истек.Значение 0 приводит к немедленному истечению срока действия ключей (фактически «Не кэшировать»).

  • ОПЦИИ : любые параметры, которые должны быть передается в бэкэнд кеша. Список допустимых вариантов будет отличаться с каждым бэкэндом, и бэкэнды кеширования, поддерживаемые сторонней библиотекой передаст свои параметры непосредственно в базовую библиотеку кеша.

    Серверные модули кеширования, которые реализуют собственную стратегию отсева (т. Е. locmem , файловая система и база данных бэкэнды) будут соблюдайте следующие параметры:

    • MAX_ENTRIES : максимальное количество записей, разрешенных в кеш перед удалением старых значений.Этот аргумент по умолчанию 300 .

    • CULL_FREQUENCY : Доля отбракованных записей. когда достигается MAX_ENTRIES . Фактическое соотношение составляет 1 / CULL_FREQUENCY , поэтому установите CULL_FREQUENCY на 2 на отбраковывать половину записей при достижении MAX_ENTRIES . Этот аргумент должно быть целым числом и по умолчанию 3 .

      Значение 0 для CULL_FREQUENCY означает, что весь кеш будет сброшен при достижении MAX_ENTRIES .На некоторых бэкэндах (в частности, в базе данных ) это делает отсечение намного большим . быстрее за счет большего количества промахов в кэше.

    Серверные модули Memcached передают содержимое OPTIONS в качестве аргументов ключевого слова для конструкторов клиента, что позволяет использовать более продвинутые контроль поведения клиентов. Пример использования см. Ниже.

  • KEY_PREFIX : строка, которая будет автоматически включается (добавляется по умолчанию) ко всем ключам кеша используется сервером Django.

    См. Документацию по кешу для больше информации.

  • ВЕРСИЯ : Номер версии по умолчанию для ключей кеша, сгенерированных сервером Django.

    Подробнее см. Документацию по кешу. Информация.

  • КЛЮЧ_ФУНКЦИЯ Строка, содержащая пунктирный путь к функции, определяющей, как чтобы составить префикс, версию и ключ в окончательный ключ кеша.

    См. Документацию по кэш-памяти. для дополнительной информации.

В этом примере серверная часть файловой системы настраивается с тайм-аутом. 60 секунд, максимальная вместимость - 1000 элементов:

 КЭШОВ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.filebased.FileBasedCache ',
        'МЕСТОПОЛОЖЕНИЕ': '/ var / tmp / django_cache',
        «ТАЙМ-АУТ»: 60,
        'ПАРАМЕТРЫ': {
            "MAX_ENTRIES": 1000
        }
    }
}
 

Вот пример конфигурации серверной части pylibmc , которая позволяет бинарный протокол, аутентификация SASL и режим поведения ketama :

 КЭШОВ = {
    'По умолчанию': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        "МЕСТО": "127.0.0.1: 11211 ',
        'ПАРАМЕТРЫ': {
            'binary': Истина,
            'имя пользователя': 'пользователь',
            'пароль': 'пароль',
            'behavior': {
                "ketama": Верно,
            }
        }
    }
}
 

Вот пример конфигурации серверной части pymemcache , которая позволяет объединение клиентов в пул (что может повысить производительность, если клиенты останутся подключенными), обрабатывает ошибки кэша памяти / сети как промахи кеша и устанавливает TCP_NODELAY флаг на разъеме подключения:

 КЭШОВ = {
    'По умолчанию': {
        'НАЗАД': 'django.core.cache.backends.memcached.PyMemcacheCache ',
        "МЕСТОПОЛОЖЕНИЕ": "127.0.0.1:11211",
        'ПАРАМЕТРЫ': {
            'no_delay': Верно,
            ignore_exc: Верно,
            'max_pool_size': 4,
            'use_pooling': Верно,
        }
    }
}
 

Кэш для каждого сайта

После настройки кеша самый простой способ использовать кеширование - это кэшировать ваши весь сайт. Вам нужно будет добавить 'django.middleware.cache.UpdateCacheMiddleware' и 'django.middleware.cache.FetchFromCacheMiddleware ' на ваш MIDDLEWARE , как в этом примере:

 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]
 

Примечание

Нет, это не опечатка: промежуточное ПО «update» должно быть первым в списке, и промежуточное ПО «выборки» должно быть последним. Детали немного неясны, но см. Порядок ПОСТОЯННОГО ОБЕСПЕЧЕНИЯ ниже, если вам нужна полная история.

Затем добавьте следующие необходимые настройки в файл настроек Django:

  • CACHE_MIDDLEWARE_ALIAS - Псевдоним кеша, используемый для хранения.
  • CACHE_MIDDLEWARE_SECONDS - Количество секунд, в течение которых каждая страница должна кэшироваться.
  • CACHE_MIDDLEWARE_KEY_PREFIX - Если кеш используется совместно несколько сайтов, использующих одну и ту же установку Django, задайте для этого имя сайт или другая строка, уникальная для этого экземпляра Django, чтобы предотвратить столкновения ключей.Если вам все равно, используйте пустую строку.

FetchFromCacheMiddleware кэширует ответы GET и HEAD со статусом 200, где позволяют заголовки запроса и ответа. Ответы на запросы о том же URL с разными параметрами запроса считаются уникальными страницами и кешируется отдельно. Это промежуточное ПО ожидает, что на запрос HEAD будет дан ответ те же заголовки ответа, что и соответствующий запрос GET; в этом случае это может вернуть кешированный ответ GET на запрос HEAD.

Кроме того, UpdateCacheMiddleware автоматически устанавливает несколько заголовков в каждый HttpResponse , который влияет на нисходящие кеши:

См. Промежуточное ПО для получения дополнительной информации о промежуточном программном обеспечении.

Если представление устанавливает собственное время истечения срока действия кеша (т.е. имеет раздел max-age в заголовок Cache-Control ), то страница будет кэшироваться до истечения срока time, а не CACHE_MIDDLEWARE_SECONDS . Использование декораторов в джанго.views.decorators.cache вы можете легко установить время истечения срока действия представления. (используя декоратор cache_control () ) или отключить кеширование для представления (используя never_cache () декоратор). Увидеть используя другой раздел заголовков, чтобы узнать больше об этих декораторах.

Если для USE_I18N установлено значение True , то сгенерированный ключ кеша будет включить название активного языка - см. также Как Django обнаруживает языковые предпочтения). Это позволяет легко кэшировать многоязычные сайты без необходимости создавать ключ кеширования самостоятельно.

Ключи кэша также включают текущий часовой пояс, если для USE_TZ установлено значение True .

Кэш на каждый просмотр¶

django.views.decorators.cache. cache_page ()

Более детальный способ использования инфраструктуры кэширования - это кэширование вывода индивидуальные взгляды. django.views.decorators.cache определяет cache_page декоратор, который автоматически кэширует для вас ответ представления:

 из django.views.decorators.cache импорт cache_page

@cache_page (60 * 15)
def my_view (запрос):
    ...
 

cache_page принимает единственный аргумент: тайм-аут кеша в секундах. в В приведенном выше примере результат представления my_view () будет кэширован на 15 минут. (Обратите внимание, что мы написали это как 60 * 15 , чтобы читаемость. 60 * 15 будет оцениваться как 900 - то есть 15 минут умноженное на 60 секунд в минуту.)

Тайм-аут кеша, установленный cache_page , имеет приоритет над max-age директива из заголовка Cache-Control .

Кэш для каждого просмотра, как и для каждого сайта, отключен от URL-адреса. Если несколько URL-адресов указывают на одно и то же представление, каждый URL-адрес будет кэшироваться отдельно. Продолжая пример my_view , если ваш URLconf выглядит так:

 urlpatterns = [
    путь ('foo /  /', my_view),
]
 

затем запросы к / foo / 1/ и / foo / 23/ будут кэшироваться отдельно, как вы можете ожидать. Но как только конкретный URL (например, / foo / 23/) был запрошено, последующие запросы к этому URL-адресу будут использовать кеш.

cache_page также может принимать необязательный аргумент ключевого слова, cache , который предписывает декоратору использовать определенный кеш (из вашего CACHES setting) при кешировании результатов просмотра. По умолчанию по умолчанию будет использоваться кеш , но вы можете указать любой кеш, который вы хочу:

 @cache_page (60 * 15, cache = "special_cache")
def my_view (запрос):
    ...
 

Вы также можете переопределить префикс кеша для каждого просмотра. cache_page принимает необязательный аргумент ключевого слова, key_prefix , который работает так же, как CACHE_MIDDLEWARE_KEY_PREFIX настройка промежуточного программного обеспечения.Его можно использовать так:

 @cache_page (60 * 15, key_prefix = "site1")
def my_view (запрос):
    ...
 

Аргументы key_prefix и cache могут быть указаны вместе. В аргумент key_prefix и KEY_PREFIX указанные в CACHES будут объединены.

Кроме того, cache_page автоматически устанавливает Cache-Control и Истекает заголовков в ответе, которые влияют на кэши нисходящего потока.

Изменено в Django 3.1:

В более старых версиях директива max-age из Cache-Control заголовок имел приоритет над тайм-аутом кеша, установленным cache_page .

Указание кеша для каждого просмотра в URLconf¶

Примеры в предыдущем разделе жестко закрепили тот факт, что представление cached, потому что cache_page заменяет функцию my_view на месте. Этот подход объединяет ваш взгляд с системой кеширования, что не идеально для нескольких причины.Например, вы можете захотеть повторно использовать функции просмотра на другом, сайт без кеша, или вы можете захотеть распространить просмотры среди людей, которые могут хотите использовать их без кеширования. Решение этих проблем - укажите кеш просмотра в URLconf, а не рядом с функциями просмотра сами себя.

Вы можете сделать это, заключив функцию просмотра в cache_page при обращении к нему в URLconf. Вот старый URLconf из более ранней версии:

 urlpatterns = [
    путь ('foo /  /', my_view),
]
 

Здесь то же самое, с my_view , завернутым в cache_page :

 из django.views.decorators.cache импорт cache_page

urlpatterns = [
    путь ('foo /  /', cache_page (60 * 15) (my_view)),
]
 

Кеширование фрагментов шаблона¶

Если вам нужен еще больший контроль, вы также можете кэшировать фрагменты шаблона, используя тег шаблона cache . Чтобы предоставить вашему шаблону доступ к этому тегу, поместите {% load cache%} в верхней части шаблона.

Тег шаблона {% cache%} кэширует содержимое блока для заданного количество времени.Требуется как минимум два аргумента: тайм-аут кеша в секундах, и имя для фрагмента кеша. Фрагмент кешируется навсегда, если таймаут Нет . Имя будет принято как есть, не используйте переменную. Для пример:

 {% загрузки кеша%}
{% cache 500 боковая панель%}
    .. боковая панель ..
{% endcache%}
 

Иногда может потребоваться кэшировать несколько копий фрагмента в зависимости от некоторые динамические данные, которые появляются внутри фрагмента. Например, вам может понадобиться отдельная кешированная копия боковой панели, использованная в предыдущем примере, для каждого пользователя вашего сайта.Сделайте это, передав один или несколько дополнительных аргументов, которые могут быть переменные с фильтрами или без них, в тег шаблона {% cache%} , чтобы однозначно идентифицировать фрагмент кеша:

 {% загрузки кеша%}
{% cache 500 sidebar request.user.username%}
    .. боковая панель для вошедшего в систему пользователя ..
{% endcache%}
 

Если для USE_I18N задано значение True , кеш промежуточного ПО для каждого сайта будет уважайте активный язык. Для шаблона cache тег, вы можете использовать один из специфичные для перевода переменные, доступные в шаблоны для достижения того же результата:

 {% load i18n%}
{% загрузки кеша%}

{% get_current_language как LANGUAGE_CODE%}

{% cache 600 добро пожаловать LANGUAGE_CODE%}
    {% translate "Добро пожаловать в пример.com "%}
{% endcache%}
 

Тайм-аут кеширования может быть переменной шаблона, если переменная шаблона разрешается в целочисленное значение. Например, если переменная шаблона my_timeout устанавливается на значение 600 , тогда следующие два примера: эквивалент:

 {% cache 600 sidebar%} ... {% endcache%}
{% cache my_timeout боковая панель%} ... {% endcache%}
 

Эта функция полезна, чтобы избежать повторения в шаблонах. Вы можете установить тайм-аут в переменной в одном месте и повторно использовать это значение.

По умолчанию тег кеша будет пытаться использовать кеш с именем «template_fragments». Если такого кеша не существует, он вернется к использованию кеша по умолчанию. Вы можете выберите альтернативный бэкэнд кеша для использования с , используя аргумент ключевого слова , который должен быть последним аргументом тега.

 {% cache 300 local-thing ... using = "localcache"%}
 

Указание не настроенного имени кэша считается ошибкой.

django.core.cache.utils. make_template_fragment_key ( имя_фрагмента , variable_on = None ) ¶

Если вы хотите получить ключ кеша, используемый для кэшированного фрагмента, вы можете использовать make_template_fragment_key . имя_фрагмента совпадает со вторым аргументом в тег шаблона cache ; variable_on - список всех дополнительных аргументов перешли в тег. Эта функция может быть полезна для аннулирования или перезаписи кэшированный элемент, например:

 >>> из django.core.cache импортный кеш
>>> из django.core.cache.utils импортировать make_template_fragment_key
# ключ кеша для {% cache 500 имя пользователя боковой панели%}
>>> key = make_template_fragment_key ('боковая панель', [имя пользователя])
>>> cache.delete (key) # делает недействительным кешированный фрагмент шаблона
Правда
 

API низкоуровневого кэша3

Иногда кеширование всей отображаемой страницы не приносит вам особой выгоды и требует собственно говоря, неудобный перебор.

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

Для подобных случаев Django предоставляет низкоуровневый API кеширования. Вы можете использовать этот API для хранения объектов в кеше с любым уровнем детализации, который вам нравится. Ты можешь кэшировать любой объект Python, который можно безопасно мариновать: строки, словари, списки объектов модели и т. д.(Наиболее распространенные объекты Python могут быть маринованный; обратитесь к документации Python для получения дополнительной информации о травление.)

Доступ к кеш-памяти¶

django.core.cache. кеши

Вы можете получить доступ к кешам, настроенным в настройке CACHES через dict-подобный объект: django.core.cache.caches . Повторяется запросы на один и тот же псевдоним в одном потоке вернут одинаковые объект.

 >>> из django.core.cache импортные кеши
>>> cache1 = кеши ['myalias']
>>> cache2 = кеши ['myalias']
>>> cache1 - это cache2
Правда
 

Если указанный ключ не существует, InvalidCacheBackendError будет поднятый.

Для обеспечения безопасности потоков другой экземпляр серверной части кеша будет возвращаться для каждого потока.

django.core.cache. кэш

В качестве ярлыка кэш по умолчанию доступен как джанго.core.cache.cache :

 >>> из кеша импорта django.core.cache
 

Этот объект эквивалентен кешам ['default'] .

Базовое использование¶

Базовый интерфейс:

кеш. установить ( ключ , значение , тайм-аут = DEFAULT_TIMEOUT , версия = нет ) ¶
 >>> cache.set ('my_key', 'привет, мир!', 30)
 
кеш. получить ( ключ , по умолчанию = нет , версия = нет ) ¶
 >>> cache.get ('my_key')
'Привет мир!'
 

ключ должен быть str , а значение может быть любым выбираемым объектом Python.

Аргумент тайм-аут является необязательным и по умолчанию используется аргумент тайм-аут соответствующего бэкэнда в настройке CACHES (объяснено выше).Это количество секунд, в течение которых значение должно храниться в кеше. Переходя в Нет для тайм-аута будет кэшировать значение навсегда. Тайм-аут из 0 не кэширует значение.

Если объект не существует в кеше, cache.get () возвращает Нет :

 >>> # Подождите 30 секунд, пока истечет срок действия my_key ...
>>> cache.get ('my_key')
Никто
 

Если вам нужно определить, существует ли объект в кеше и у вас есть сохранено буквальное значение Нет , по умолчанию используется объект-дозорный:

 >>> часовой = объект ()
>>> кеш.get ('my_key', sentinel) - дозорный
Ложь
>>> # Подождите 30 секунд, пока истечет срок действия my_key ...
>>> cache.get ('my_key', sentinel) - дозорный
Правда
 

MemcachedCache

Из-за ограничения python-memcached невозможно различить между сохраненным значением Нет и промахом в кэше, обозначенным возвращаемым значением из Нет на устаревшем сервере MemcachedCache .

cache.get () может принимать аргумент по умолчанию .Это указывает, какое значение вернуть, если объекта нет в кеше:

 >>> cache.get ('my_key', 'истек')
'истек'
 
кеш. добавить ( ключ , значение , тайм-аут = DEFAULT_TIMEOUT , версия = Нет ) ¶

Чтобы добавить ключ, только если он еще не существует, используйте метод add () . Он принимает те же параметры, что и set () , но не пытается обновить кеш, если указанный ключ уже присутствует:

 >>> кеш.set ('add_key', 'Начальное значение')
>>> cache.add ('add_key', 'Новое значение')
>>> cache.get ('add_key')
'Начальное значение'
 

Если вам нужно знать, хранит ли add () значение в кеше, вы можете проверьте возвращаемое значение. Он вернет True , если значение было сохранено, Неверно иначе.

кеш. get_or_set ( key , default , timeout = DEFAULT_TIMEOUT , version = None ) ¶

Если вы хотите получить значение ключа или установить значение, если ключа нет в кеше, есть метод get_or_set () .Принимает те же параметры, что и get () но по умолчанию устанавливается новое значение кеша для этого ключа, а не возвращено:

 >>> cache.get ('my_new_key') # не возвращает None
>>> cache.get_or_set ('my_new_key', 'мое новое значение', 100)
"моя новая ценность"
 

Вы также можете передать любой вызываемый объект как значение по умолчанию :

 >>> импорт datetime
>>> cache.get_or_set ('ключ-отметки времени', datetime.datetime.now)
datetime.datetime (2014, 12, 11, 0, 15, 49, 457920)
 
кеш. get_many ( ключей , версия = нет ) ¶

Существует также интерфейс get_many () , который попадает в кеш только один раз. get_many () возвращает словарь со всеми ключами, которые вы просили для этого действительно существуют в кеше (и срок их действия не истек):

 >>> cache.set ('а', 1)
>>> cache.set ('b', 2)
>>> cache.set ('c', 3)
>>> cache.get_many (['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}
 
кеш. set_many ( dict , таймаут ) ¶

Чтобы установить несколько значений более эффективно, используйте set_many () для передачи словаря пар ключ-значение:

 >>> cache.set_many ({'a': 1, 'b': 2, 'c': 3})
>>> cache.get_many (['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}
 

Как и cache.set () , set_many () принимает необязательный параметр timeout .

На поддерживаемых серверных ВМ (memcached) set_many () возвращает список ключей, которые не удалось вставить.

кеш. удалить ( ключ , версия = нет ) ¶

Вы можете удалить ключи явно с помощью delete () , чтобы очистить кеш для конкретный объект:

 >>> cache.delete ('а')
Правда
 

delete () возвращает True , если ключ был успешно удален, False иначе.

Изменено в Django 3.1:

Добавлено логическое возвращаемое значение.

кеш. delete_many ( ключей , версия = Нет ) ¶

Если вы хотите очистить сразу несколько ключей, delete_many () может взять список ключей, подлежащих очистке:

 >>> cache.delete_many (['a', 'b', 'c'])
 
кеш. прозрачный () ¶

Наконец, если вы хотите удалить все ключи в кеше, используйте cache.clear () . Будьте осторожны с этим; clear () удалит все из кеша, а не только ключи, установленные вашим приложением.

кеш. сенсорный ( клавиша , тайм-аут = DEFAULT_TIMEOUT , версия = нет ) ¶

cache.touch () устанавливает новый срок действия ключа. Например, чтобы обновить ключ срок действия истекает через 10 секунд:

 >>> cache.touch ('а', 10)
Правда
 

Как и другие методы, аргумент timeout является необязательным и по умолчанию TIMEOUT вариант соответствующего бэкэнда в настройке CACHES .

touch () возвращает Истина , если клавиша была успешно нажата, Ложь иначе.

кеш. incr ( ключ , дельта = 1 , версия = нет ) ¶
кеш. decr ( ключ , дельта = 1 , версия = нет ) ¶

Вы также можете увеличивать или уменьшать уже существующий ключ, используя incr () или decr () соответственно.По умолчанию существующий кеш значение будет увеличиваться или уменьшаться на 1. Другие значения увеличения / уменьшения можно указать, предоставив аргумент для вызова увеличения / уменьшения. А ValueError будет вызвано, если вы попытаетесь увеличить или уменьшить несуществующий ключ кеша .:

 >>> cache.set ('число', 1)
>>> cache.incr ('число')
2
>>> cache.incr ('число', 10)
12
>>> cache.decr ('число')
11
>>> cache.decr ('число', 5)
6
 

Примечание

incr () / decr () не гарантируется, что они будут атомарными.На тех бэкэнды, поддерживающие атомарное приращение / декремент (в первую очередь, memcached backend) операции увеличения и уменьшения будут атомарными. Однако, если бэкэнд изначально не обеспечивает увеличение / уменьшение операция, она будет реализована с использованием двухэтапного извлечения / обновления.

кеш. закрыть () ¶

Вы можете закрыть соединение с кешем с помощью close () , если это реализовано бэкэнд кеша.

Примечание

Для кешей, которые не реализуют методы close , это не работает.

Префикс ключа кеша¶

Если вы разделяете экземпляр кеша между серверами или между вашими среды производства и разработки, возможно кэширование данных одним сервером для использования другим сервером. Если формат кешированного данные на разных серверах различаются, это может привести к тому, что некоторые диагностировать проблемы.

Чтобы предотвратить это, Django предоставляет возможность добавлять префиксы ко всем ключам кеша. используется сервером. Когда определенный ключ кеша сохраняется или извлекается, Django автоматически префикс ключа кеша со значением KEY_PREFIX настройка кеша.

Убедившись, что каждый экземпляр Django имеет разные KEY_PREFIX , вы можете быть уверены, что не будет коллизии в значениях кеша.

Управление версиями кэша¶

Когда вы изменяете работающий код, который использует кешированные значения, вам может потребоваться очистить все существующие кэшированные значения. Самый простой способ сделать это - очистить весь кеш, но это может привести к потере значений кеша которые по-прежнему актуальны и полезны.

Django предоставляет лучший способ нацеливать отдельные значения кеша.Фреймворк кеширования Django имеет общесистемный идентификатор версии, указывается с помощью параметра кеширования ВЕРСИЯ . Значение этого параметра автоматически комбинируется с кешем. префикс и предоставленный пользователем ключ кеша для получения окончательного ключа кеша.

По умолчанию любой ключевой запрос будет автоматически включать сайт версия ключа кеша по умолчанию. Однако примитивный кеш функционирует все включить аргумент версии , чтобы вы могли указать конкретный кеш версия ключа, которую нужно установить или получить.Например:

 >>> # Установить версию 2 ключа кеша
>>> cache.set ('my_key', 'привет, мир!', версия = 2)
>>> # Получить версию по умолчанию (при условии, что версия = 1)
>>> cache.get ('my_key')
Никто
>>> # Получить 2 версию того же ключа
>>> cache.get ('my_key', версия = 2)
'Привет мир!'
 

Версия определенного ключа может увеличиваться и уменьшаться с помощью методы incr_version () и decr_version () . Этот позволяет перенести определенные ключи на новую версию, оставляя другие ключи не затронуты.Продолжая наш предыдущий пример:

 >>> # Увеличить версию my_key
>>> cache.incr_version ('my_key')
>>> # Версия по умолчанию все еще недоступна
>>> cache.get ('my_key')
Никто
# Версия 2 также недоступна
>>> cache.get ('my_key', версия = 2)
Никто
>>> # Но есть версия 3 * *
>>> cache.get ('my_key', версия = 3)
'Привет мир!'
 

Преобразование ключа кэша¶

Как описано в предыдущих двух разделах, ключ кеша, предоставляемый user не используется дословно - он сочетается с префиксом кеша и key version, чтобы предоставить окончательный ключ кеша.По умолчанию три части соединяются с использованием двоеточия для получения последней строки:

 def make_key (ключ, префикс ключа, версия):
    вернуть '% s:% s:% s'% (префикс_ключа, версия, ключ)
 

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

Настройка кэша KEY_FUNCTION указывает пунктирный путь к функции, соответствующей прототипу make_key () выше.Если эта функция предусмотрена, эта настраиваемая клавиша будет использоваться вместо функции комбинирования клавиш по умолчанию.

Предупреждения о ключах кеширования¶

Memcached, наиболее часто используемый серверный модуль кеширования, не позволяет ключи кеша длиннее 250 символов или содержащие пробелы или элементы управления символов, и использование таких ключей вызовет исключение. Поощрять кеш-переносимый код и минимизация неприятных сюрпризов, другой встроенный кеш бэкенды выдают предупреждение ( django.core.cache.backends.base.CacheKeyWarning ) если используется ключ, это вызовет ошибку в memcached.

Если вы используете производственный бэкэнд, который может принимать более широкий диапазон ключей ( пользовательский бэкэнд или один из встроенных бэкэндов без memcached) и хотите использовать этот более широкий диапазон без предупреждений, вы можете отключить CacheKeyWarning с этот код в модуле управления одного из ваших УСТАНОВЛЕННЫЕ ПРИЛОЖЕНИЯ :

 предупреждений об импорте

из django.core.cache импорт CacheKeyWarning

предупреждения.simplefilter ("игнорировать", CacheKeyWarning)
 

Если вместо этого вы хотите предоставить настраиваемую логику проверки ключа для одного из встроенные бэкэнды, вы можете создать подклассы, переопределив только validate_key и следуйте инструкциям по использованию настраиваемого серверного модуля кеширования. Для Например, чтобы сделать это для бэкэнда locmem , поместите этот код в модуль:

 из django.core.cache.backends.locmem импортировать LocMemCache

класс CustomLocMemCache (LocMemCache):
    def validate_key (сам, ключ):
        "" "Пользовательская проверка, создание исключений или предупреждений по мере необходимости."" "
        ...
 

… и используйте пунктирный путь Python к этому классу в BACKEND часть вашей настройки CACHES .

Кэш нисходящего потока¶

До сих пор в этом документе основное внимание уделялось кэшированию ваших собственных данных . Но другой тип кэширования актуально и для веб-разработки: кеширование выполняется «Нисходящие» кеши. Это системы, которые кэшируют страницы для пользователей еще до того, как запрос достигает вашего веб-сайта.

Вот несколько примеров нисходящих кешей:

  • При использовании HTTP ваш провайдер может кэшировать определенные страницы, поэтому, если вы запросили страницу из http: // example.com / , ваш Интернет-провайдер отправит вам страницу без прямого доступа к example.com. Сопровождающие example.com ничего не знают об этом кэшировании; провайдер находится между example.com и вашим веб-браузером, обрабатывая все кэширование прозрачно. Такое кеширование невозможно по протоколу HTTPS, как это было бы представляют собой атаку "человек посередине".
  • Ваш сайт Django может находиться за прокси-кешем , например Squid Web Прокси-кеш (http://www.squid-cache.org/), который кэширует страницы для представление.В этом случае каждый запрос сначала будет обрабатываться прокси, и он будет передан вашему приложению только в случае необходимости.
  • Ваш веб-браузер тоже кэширует страницы. Если веб-страница отправляет соответствующие заголовки, ваш браузер будет использовать локальную кешированную копию для последующие запросы к этой странице, даже не обращаясь к веб-странице еще раз, чтобы увидеть, изменилось ли оно.

Нисходящее кэширование - хороший прирост эффективности, но в этом есть опасность: Содержание многих веб-страниц различается в зависимости от аутентификации и множества других переменные и системы кеширования, которые вслепую сохраняют страницы исключительно на основе URL-адресов, могут предоставлять неверные или конфиденциальные данные последующим посетителям этих страниц.

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

К счастью, HTTP предоставляет решение этой проблемы. Количество заголовков HTTP существуют, чтобы дать указание нижестоящим кешам различать их содержимое кеша в зависимости от обозначенные переменные, и сообщить механизмам кэширования не кэшировать определенные страниц.Мы рассмотрим некоторые из этих заголовков в следующих разделах.

Использование заголовков

Vary

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

По умолчанию система кеширования Django создает свои ключи кеша, используя запрошенные полный URL - например,, "https://www.example.com/stories/2005/?order_by=author" . Это означает, что каждый запрос к этому URL-адресу будет использовать ту же кешированную версию, независимо от пользовательского агента различия, такие как файлы cookie или языковые предпочтения. Однако, если эта страница создает разный контент на основе некоторой разницы в заголовках запросов - например, в качестве файла cookie, языка или агента пользователя - вам необходимо использовать Vary заголовок, чтобы сообщить механизмам кэширования, что вывод страницы зависит от этих вещей.

Для этого в Django используйте удобный джанго.views.decorators.vary.vary_on_headers () декоратор представления, например:

 из django.views.decorators.vary import var_on_headers

@vary_on_headers ("Пользователь-агент")
def my_view (запрос):
    ...
 

В этом случае механизм кэширования (такой как собственное промежуточное ПО кеширования Django) будет кешировать отдельную версию страницы для каждого уникального пользовательского агента.

Преимущество использования декоратора Different_on_headers , а не вручную установка заголовка Vary (используя что-то вроде ответа .заголовки ['Vary'] = 'user-agent' ) заключается в том, что декоратор добавляет к заголовку Vary (который может уже существует), а не устанавливать его с нуля и потенциально переопределять все, что уже было там.

Вы можете передать несколько заголовков в Different_on_headers () :

 @vary_on_headers ('User-Agent', 'Cookie')
def my_view (запрос):
    ...
 

Это говорит о том, что нижестоящие кеши изменяются на и , что означает, что каждая комбинация user-agent и cookie получат собственное значение кеша.Например, запрос с будет учитываться пользовательский агент Mozilla и значение cookie foo = bar отличается от запроса с пользовательским агентом Mozilla и значением cookie foo = ветчина .

Поскольку изменение файлов cookie является обычным явлением, существует django.views.decorators.vary.vary_on_cookie () декоратор. Эти два взгляда эквивалентны:

 @vary_on_cookie
def my_view (запрос):
    ...

@vary_on_headers ('Cookie')
def my_view (запрос):
    ...
 

Заголовки, которые вы передаете в Different_on_headers , не чувствительны к регистру; «User-Agent» - это то же самое, что «user-agent» .

Вы также можете использовать вспомогательную функцию django.utils.cache.patch_vary_headers () , напрямую. Эта функция устанавливает или дополняет заголовок Vary . Например:

 из django.shortcuts import render
из django.utils.cache импортировать patch_vary_headers

def my_view (запрос):
    ...
    response = render (запрос, 'имя_шаблона', контекст)
    patch_vary_headers (ответ, ['Cookie'])
    ответ на ответ
 

patch_vary_headers принимает экземпляр HttpResponse как его первый аргумент и список / кортеж имен заголовков без учета регистра в качестве его Второй аргумент.

Подробнее о заголовках Vary см. В официальной спецификации Vary .

Управление кешем: использование других заголовков¶

Другие проблемы с кешированием - это конфиденциальность данных и вопрос о том, где данные должны храниться в каскаде кешей.

Пользователь обычно сталкивается с двумя типами кешей: их собственный кеш браузера (частный cache) и кеш их провайдера (публичный кеш). Публичный кеш используется несколько пользователей и контролируются кем-то другим. Это создает проблемы с конфиденциальные данные - например, вы не хотите, чтобы номер вашего банковского счета хранился в публичный кеш.Таким образом, веб-приложениям нужен способ сообщать кешам, какие данные частный и публичный.

Решение состоит в том, чтобы указать, что кеш страницы должен быть «частным». Сделать это в Django, используйте представление cache_control () декоратор. Пример:

 из django.views.decorators.cache импорт cache_control

@cache_control (частный = True)
def my_view (запрос):
    ...
 

Этот декоратор заботится об отправке соответствующего HTTP-заголовка за сцены.

Обратите внимание, что параметры управления кешем «частный» и «общедоступный» взаимно эксклюзивный.Декоратор гарантирует, что директива public будет удалена, если «Частный» должен быть установлен (и наоборот). Пример использования двух директив был бы сайтом блога, который предлагает как частные, так и публичные записи. Общественные записи могут кэшироваться в любом общем кэше. В следующем коде используется patch_cache_control () , ручной способ изменения заголовок управления кешем (он вызывается изнутри cache_control () декоратор):

 из django.views.decorators.cache импортировать patch_cache_control
из джанго.views.decorators.vary import var_on_cookie

@vary_on_cookie
def list_blog_entries_view (запрос):
    если request.user.is_anonymous:
        response = render_only_public_entries ()
        patch_cache_control (ответ, общедоступный = True)
    еще:
        response = render_private_and_public_entries (request.user)
        patch_cache_control (ответ, частный = True)

    ответ на ответ
 

Вы можете управлять кэшем нисходящего потока и другими способами (см. RFC 7234 для подробности о HTTP-кешировании).Например, даже если вы не используете Django’s фреймворк кеширования на стороне сервера, вы все равно можете указать клиентам кэшировать представление для определенное количество времени с max-age директива:

 из django.views.decorators.cache импорт cache_control

@cache_control (max_age = 3600)
def my_view (запрос):
    ...
 

(Если вы и используете промежуточное ПО кэширования, оно уже устанавливает max-age с значение параметра CACHE_MIDDLEWARE_SECONDS . В этом случае, кастом max_age из cache_control () декоратор примет приоритет, и значения заголовков будут правильно объединены.)

Любая допустимая директива ответа Cache-Control действительна в cache_control () . Вот еще несколько примеров:

  • no_transform = Истина
  • must_revalidate = True
  • устаревшее_time_revalidate = num_seconds
  • no_cache = Истина

Полный список известных директив можно найти в реестре IANA. (обратите внимание, что не все из них применимы к ответам).

Если вы хотите использовать заголовки для полного отключения кеширования, never_cache () - декоратор представления, добавляет заголовки, чтобы гарантировать, что ответ не будет кеширован браузерами или другими тайники.Пример:

 из django.views.decorators.cache импорт never_cache

@ Never_cache
def myview (запрос):
    ...
 

Заказ

СРЕДНЕЕ ОБЕСПЕЧЕНИЕ

Если вы используете промежуточное ПО для кэширования, важно размещать каждую половину в правильном поместите в настройку MIDDLEWARE . Это потому, что кеш промежуточному программному обеспечению необходимо знать, какие заголовки используются для изменения кеш-хранилища. Промежуточное ПО всегда добавляет что-то в заголовок ответа Vary , когда это возможно.

UpdateCacheMiddleware запускается во время фазы ответа, где промежуточное ПО выполняются в обратном порядке, поэтому элемент в верхней части списка запускает последних во время фаза ответа. Таким образом, вам необходимо убедиться, что UpdateCacheMiddleware появляется перед , любое другое промежуточное ПО, которое может что-то добавить к Vary заголовок. Следующие промежуточные модули делают это:

  • SessionMiddleware добавляет Cookie
  • GZipMiddleware добавляет Accept-Encoding
  • LocaleMiddleware добавляет Accept-Language

FetchFromCacheMiddleware , с другой стороны, выполняется на этапе запроса, где промежуточное ПО применяется в порядке очереди, поэтому элемент в верхней части списка запускает первые на этапе запроса. FetchFromCacheMiddleware также должен запускаться после того, как другое промежуточное ПО обновит заголовок Vary , поэтому FetchFromCacheMiddleware должно быть после любого элемента, который это делает.

.