You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by tibor katelbach <oc...@gmail.com> on 2007/01/15 15:40:58 UTC
great CPU optimisation on calculate price
Hi everyone
Here's how we managed to gain great performance optimisation overall. This
divided our CPU consuption by half.
Optimisation Price Rule through Cache
<http://192.168.215.62:8000/trac/wiki/priceRules#OptimisationPriceRulethroughCache>
Since calculateProductPrice is used at every/any time a product is viewed
(category page, product page, addToCart) and whenever Price Rules are
applied, we can optimize the access to this Service by using Ofbiz's
UtilCache System. This means that instead of recalculating a product price
at every visit, when entering the calculatePrice Service an existence check
is made in the Product Price cache with a catalog+productId key.
- If it exist it will simply return the Map this Service should have
returned for this ProductId
- otherwise it will execute the complete Service, save the result to
Cache for the next visit, and return the requested result.
Our use case needed more than 4000 Price Rules to be applied. This
drastically slowed down ofbiz's performance. This Caching process can be
used for any recurent service call.
Existence Check and Return
<http://192.168.215.62:8000/trac/wiki/priceRules#ExistenceCheckandReturn>
UtilCache productPricesCache = (UtilCache)
UtilCache.utilCacheTable.get("productPriceCache");
if (productPricesCache == null)
productPricesCache = new UtilCache("productPriceCache",0,0);
String productPriceCacheKey =
productId+prodCatalogId+webSiteId+productStoreId+productStoreGroupId;
//if Cache exists
if (productPricesCache != null)
{
Map productPrice = (Map)productPricesCache.get(productPriceCacheKey);
//if the Key exists
if(productPrice!=null)
return productPrice;
}
//else if cache key doesn't exist go through the whole service
// build the result Map
//add it to the Cache for the next Visit
productPricesCache.put(productPriceCacheKey,result);
return result;
Important Clear Cache
<http://192.168.215.62:8000/trac/wiki/priceRules#ImportantClearCache>
Offcourse since Price Rules Change, or Product Prices Change the cache needs
to be emptied according to project internal rules so that Product Prices
contain the result of a modification.
- for a specific Cache Cleanup Method :
UtilCache.clearCache("productPriceCache");
- for a global Cache Clean Method : UtilCache.clearAll();
in our use case , we have a clear cache that is made
- on each Synchronisation
- every time a price rule is manuelly modified (on Back Office price
rule form update submit )
- every day scheduled job at 00h00, since this is when some price
rules can end
Best Regards
Tibor
Re: great CPU optimisation on calculate price
Posted by Jonathon -- Improov <jo...@improov.com>.
No problems with this approach. Except...
Isn't it possible to clear specific cache lines in a cache? More fine-grained.
We will need to do a good comb-through to find all spots in OFBiz where the price rule can be
affected. For each of those spots, wire in a "cache clear" or "cache recalculate".
A good way to do this in OFBiz is to use the EECAs.
That covers the 2nd cache clear item in Tibor's list of 3 cache clear items.
For Tibor's 3rd cache clear item, it might be more reliable (cache updates more timely) if we use
JobSandbox to schedule a recalculation of price rules for each expiration time.
I don't understand Tibor's 1st cache clear item (Synchronization). Will there be more than 1
database? If so, yes, a cache clear here and a recalculation is required.
Jonathon
jacques.le.roux wrote:
> Hi all,
>
> I wonder if someone has applied this trick or/and if somebody can see any
> flaws in it (of course clearing caches depends of usage and should be very
> carefully done...)
>
> Thanks for any comments
>
> Jacques
>
>
> tibor katelbach wrote:
>> Hi everyone
>>
>> Here's how we managed to gain great performance optimisation overall. This
>> divided our CPU consuption by half.
>>
>> Optimisation Price Rule through Cache
>> <http://192.168.215.62:8000/trac/wiki/priceRules#OptimisationPriceRulethroughCache>
>>
>> Since calculateProductPrice is used at every/any time a product is viewed
>> (category page, product page, addToCart) and whenever Price Rules are
>> applied, we can optimize the access to this Service by using Ofbiz's
>> UtilCache System. This means that instead of recalculating a product price
>> at every visit, when entering the calculatePrice Service an existence
>> check
>> is made in the Product Price cache with a catalog+productId key.
>>
>> - If it exist it will simply return the Map this Service should have
>> returned for this ProductId
>> - otherwise it will execute the complete Service, save the result to
>> Cache for the next visit, and return the requested result.
>>
>> Our use case needed more than 4000 Price Rules to be applied. This
>> drastically slowed down ofbiz's performance. This Caching process can be
>> used for any recurent service call.
>> Existence Check and Return
>> <http://192.168.215.62:8000/trac/wiki/priceRules#ExistenceCheckandReturn>
>>
>> UtilCache productPricesCache = (UtilCache)
>> UtilCache.utilCacheTable.get("productPriceCache");
>> if (productPricesCache == null)
>> productPricesCache = new UtilCache("productPriceCache",0,0);
>> String productPriceCacheKey =
>> productId+prodCatalogId+webSiteId+productStoreId+productStoreGroupId;
>> //if Cache exists
>> if (productPricesCache != null)
>> {
>> Map productPrice =
>> (Map)productPricesCache.get(productPriceCacheKey);
>> //if the Key exists
>> if(productPrice!=null)
>> return productPrice;
>> }
>>
>> //else if cache key doesn't exist go through the whole service
>> // build the result Map
>> //add it to the Cache for the next Visit
>> productPricesCache.put(productPriceCacheKey,result);
>> return result;
>>
>> Important Clear Cache
>> <http://192.168.215.62:8000/trac/wiki/priceRules#ImportantClearCache>
>>
>> Offcourse since Price Rules Change, or Product Prices Change the cache
>> needs
>> to be emptied according to project internal rules so that Product Prices
>> contain the result of a modification.
>>
>> - for a specific Cache Cleanup Method :
>> UtilCache.clearCache("productPriceCache");
>>
>> - for a global Cache Clean Method : UtilCache.clearAll();
>>
>> in our use case , we have a clear cache that is made
>>
>> - on each Synchronisation
>> - every time a price rule is manuelly modified (on Back Office price
>> rule form update submit )
>> - every day scheduled job at 00h00, since this is when some price
>> rules can end
>>
>>
>>
>> Best Regards
>> Tibor
>>
>>
>
Re: great CPU optimisation on calculate price
Posted by "jacques.le.roux" <ja...@les7arts.com>.
Hi all,
I wonder if someone has applied this trick or/and if somebody can see any
flaws in it (of course clearing caches depends of usage and should be very
carefully done...)
Thanks for any comments
Jacques
tibor katelbach wrote:
>
> Hi everyone
>
> Here's how we managed to gain great performance optimisation overall. This
> divided our CPU consuption by half.
>
> Optimisation Price Rule through Cache
> <http://192.168.215.62:8000/trac/wiki/priceRules#OptimisationPriceRulethroughCache>
>
> Since calculateProductPrice is used at every/any time a product is viewed
> (category page, product page, addToCart) and whenever Price Rules are
> applied, we can optimize the access to this Service by using Ofbiz's
> UtilCache System. This means that instead of recalculating a product price
> at every visit, when entering the calculatePrice Service an existence
> check
> is made in the Product Price cache with a catalog+productId key.
>
> - If it exist it will simply return the Map this Service should have
> returned for this ProductId
> - otherwise it will execute the complete Service, save the result to
> Cache for the next visit, and return the requested result.
>
> Our use case needed more than 4000 Price Rules to be applied. This
> drastically slowed down ofbiz's performance. This Caching process can be
> used for any recurent service call.
> Existence Check and Return
> <http://192.168.215.62:8000/trac/wiki/priceRules#ExistenceCheckandReturn>
>
> UtilCache productPricesCache = (UtilCache)
> UtilCache.utilCacheTable.get("productPriceCache");
> if (productPricesCache == null)
> productPricesCache = new UtilCache("productPriceCache",0,0);
> String productPriceCacheKey =
> productId+prodCatalogId+webSiteId+productStoreId+productStoreGroupId;
> //if Cache exists
> if (productPricesCache != null)
> {
> Map productPrice =
> (Map)productPricesCache.get(productPriceCacheKey);
> //if the Key exists
> if(productPrice!=null)
> return productPrice;
> }
>
> //else if cache key doesn't exist go through the whole service
> // build the result Map
> //add it to the Cache for the next Visit
> productPricesCache.put(productPriceCacheKey,result);
> return result;
>
> Important Clear Cache
> <http://192.168.215.62:8000/trac/wiki/priceRules#ImportantClearCache>
>
> Offcourse since Price Rules Change, or Product Prices Change the cache
> needs
> to be emptied according to project internal rules so that Product Prices
> contain the result of a modification.
>
> - for a specific Cache Cleanup Method :
> UtilCache.clearCache("productPriceCache");
>
> - for a global Cache Clean Method : UtilCache.clearAll();
>
> in our use case , we have a clear cache that is made
>
> - on each Synchronisation
> - every time a price rule is manuelly modified (on Back Office price
> rule form update submit )
> - every day scheduled job at 00h00, since this is when some price
> rules can end
>
>
>
> Best Regards
> Tibor
>
>
--
View this message in context: http://www.nabble.com/great-CPU-optimisation-on-calculate-price-tf3014955.html#a13592664
Sent from the OFBiz - User mailing list archive at Nabble.com.