CacheProductPrices - should not be enabled if we use 'complex' discount requirements. Why?

We have some nopcommerce solutions with quite heavy traffic, at least under campaign periods.

I want to increase performance, and i know caching prices can increase performance. However, according to this message it should not be enabled if we have discount requirements:


What is the reason for that? The price is calculated correctly anyways right? Is it a memory issue?

Discount requirement rules or discount rules could be quite complex. That's the only reason why we do not recommend  enabling caching. Please check "GetFinalPriceAsync" method in the "PriceCalculationService" class. It has a list of params for the "NopCatalogDefaults.ProductPriceCacheKey" key. Just ensure that your discounting logic will be covered by all these keys. In this case you can enable this setting

Will do. Thanks!

I cant see anything thats missing from the params. Do you know of any complex rules which is default nop thats missing?

I believe Andrei is referring to these "params"

var cacheKey = _staticCacheManager.PrepareKeyForDefaultCache(NopCatalogDefaults.ProductPriceCacheKey, 
    product,
    overriddenProductPrice,
    additionalCharge,
    includeDiscounts,
    quantity,
    await _customerService.GetCustomerRoleIdsAsync(customer),
    store);

New York wrote:

Yeah, i just screenshotted the documentation of the params to make it easier :)

But what you screenshotted are the params of method GetFinalPriceAsync.
The params of concern are those of method PrepareKeyForDefaultCache.

New York wrote:
Ah, sorry about that, i screenshotted 2 times and the wrong one was pasted :(

But yeah, can u imagine any rules not being counted if we cache prices? As far as i can see it checks for customer roles restrictions and everything else. But rules added by other plugins like 2 for 1 etc would probably be an issue, but we dont use that at this store.

The only parameter in the key regarding discounts is the Boolean includeDiscounts.  Without tracing through source code (or other testing), I don't know what the impact on product's cached price is if things change between the initially cached value and the subsequent retrieval.  Discounts are somewhat "dynamic" even without regards to Discount Requirement Rule plugins - e.g.
a) price is initially cached within or not within discount's Start/End date
b) customer enters a coupon, but then removes it and or add another
c) Discount limitation is reached

New York wrote:

I think i might rewrite the GetFinalPrice method to use ShortTermCacheKey instead, so I'm sure that discounts are at least correct after 300 sec. We have integrations to ERP systems updating prices, and that takes some minutes anyways. The only reason i want caching for prices is to lower the server load on campaigns