ASP.net — кэширование по строке запроса (VaryByParam)

В каких ситуациях мы должны использовать Query-Strings (VaryByParam) для достижения кэширования в ASP.NET?

Может ли кто-нибудь привести пример реальной ситуации в случае веб-приложения?


caching asp.net query-string outputcache
person user366312    schedule 24.07.2009    source источник
comment
когда вы хотите кэшировать страницы на основе различных параметров....   -  person Mitch Wheat    schedule 24.07.2009
comment
Сколько уникальных строк запроса вы ожидаете иметь? Я рассматривал кэширование VaryVyParam только тогда, когда количество возможных вариантов невелико (чтобы предотвратить чрезмерное кэширование).   -  person Kurt Schindler    schedule 24.07.2009
comment
@Mitch Wheat, ответ примерно такой... В: Где находится Канада? Ответ: На планете Земля. (!!!!!)   -  person    schedule 24.07.2009
comment
@Mitch Wheat, а почему ты достаточно уверен в себе, чтобы проголосовать за закрытие этой темы?   -  person    schedule 24.07.2009

Ответы (2)


arrow_upward
4
arrow_downward 

Products.aspx?productID=12345

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

В деталях

Если я нажму Products.aspx?productID=12345, страница будет обработана для меня, я найду информацию о продукте 12345 и кэширую результаты. Затем вы нажмете Products.aspx?productID=54321, страница не будет обработана для вас, но products.aspx будет извлечен из кэша вывода, и вы увидите информацию для 12345. Нехорошо. VaryByParam решает эту проблему.

person Rex M    schedule 24.07.2009
comment
Вы правы, конечно. Может быть, я прочитал вопрос под другим углом, но мой вопрос будет таков: действительно ли вы вообще хотите кэшировать эту страницу? У вас может быть столько страниц в кеше, сколько у вас продуктов, и, по моим подсчетам, их может быть целых 12 345! ;) - person Kurt Schindler; 24.07.2009
comment
@Kurt, конечно, это звонок, который вам нужно сделать, исходя из ряда факторов. Если страницы вашего продукта чрезвычайно интенсивно используют БД; у вас достаточно повторного трафика на страницы продуктов, чтобы оправдать их кеширование, и у вас есть 32 ГБ памяти на ваших веб-интерфейсах, почему бы не кэшировать 100 000 страниц продуктов по 25 000 каждая - это меньше 3 ГБ памяти. - person Rex M; 24.07.2009

arrow_upward
2
arrow_downward

Самым классическим примером может быть: Каталог товаров.

Он может иметь такую ​​структуру URL:

http://www.myshop.com/Catalog/ViewAllProducts.aspx

http://www.myshop.com/Catalog/ViewAllProducts.aspx?PageNum=123&PageSize=50

http://www.myshop.com/Catalog/ViewProduct.aspx?ProductID=12345

Первый URL — это полный список всех продуктов. Здесь нет строки запроса, но второй URL — это та же страница, но с нумерацией страниц. Номер страницы (PageNum) и количество элементов на странице (PageSize) являются строками запроса, поэтому, если пользователь не может изменить порядок списка продуктов, два разных пользователя запрашивают:

http://www.myshop.com/Catalog/ViewAllProducts.aspx?PageNum=123&PageSize=50

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

Третий URL-адрес — это экран сведений об одном продукте с идентификатором продукта (который может быть уникальным идентификатором из базы данных) в качестве единственного параметра строки запроса. Несколько запросов для этого почти всегда должны возвращать одни и те же данные (если только цена, описание или какой-либо другой элемент этого конкретного продукта не меняется на частой основе). Кэширование на основе строки запроса «ProductID» (и ее значений для разных продуктов) значительно снизит нагрузку на базу данных. Убедившись, что продолжительность кэша не слишком велика, вы гарантируете, что срок действия кэша истечет в разумные сроки, если фактические данные серверной базы данных изменятся.

person CraigTP    schedule 24.07.2009