It's certainly possible that with a system that has a high volume of updates, on certain entities, that caching will degrade performance on a single-server or clustered environment.
I would certainly suggest that for constantly changing that caching be turned off, or have a quick expiration. For you that could be Orders and related entities as they move through the manufacturing / fulfillment process? I'm sure you probably have a good sense as to the system usage, where high-volume updates take place, and how that impacts specific DB entities. Even in our eCommerce implementations we do not cache Order related data. We focus on the heavy usage / read-only aspects (Product catalog and related). It may take some experimentation to really get to the solution. Interested to hear about your experience. Nick -----Original Message----- From: Jacques Le Roux [mailto:[email protected]] Sent: Wednesday, June 29, 2016 3:09 AM To: [email protected] Subject: Re: Aw: Re: Memcached / central caching Ah forgot, Moqui is using http://www.ehcache.org/ Le 29/06/2016 à 08:55, Jacques Le Roux a écrit : > Thanks Leonard, > > So it could be indeed that DCC does not support this case well. It > would be interesting to know why. Of course using something like memcached is > certainly a good way and a contribution would be quite welcome! > > Jacques > > > Le 29/06/2016 à 08:33, Leonard Lin a écrit : >> Thanks for the input. >> I have to try to look at logs to see which entities/processes are the high >> cache clear flow. >> We are not using our ofbiz as an ecommerce system but as the >> manufacturing/fulfillment system. >> We do process a lot of orders and have also custom modules. >> >> Gesendet: Montag, 27. Juni 2016 um 15:46 Uhr >> Von: "Jacques Le Roux" <[email protected]> >> An: [email protected] >> Betreff: Re: Memcached / central caching I can confirm this behaviour >> (working well and better with more instances to support the growing >> load) for a configuration of 5 OFBiz machines against a cluster of 3 >> Postgres machines (using PgPool II). >> >> It was also for an ecommerce application for a major Internet >> provider. I then I wrote the wiki page about DCC. As say Nick, you may >> indeed have a specific issue we did not cross... >> >> Jacques >> >> >> Le 27/06/2016 à 15:11, Nick Rosser a écrit : >>> Leonard, >>> >>> We have clients using distributed cache -- we used ActiveMQ to >>> synchronize any cache modifications from one server to the other(s). Worked >>> very well -- and we saw a significant performance uptick when adding >>> additional "slave" instances. >>> >>> Our implementations are typically for eCommerce -- with minimal cache-clear >>> events. >>> >>> Which entities are subject to high volume cache-clear events for you? >>> Perhaps you could consider removing caching for those entities? >>> >>> Nick >>> >>> -----Original Message----- >>> From: Leonard Lin [mailto:[email protected]] >>> Sent: Monday, June 27, 2016 6:24 AM >>> To: [email protected] >>> Subject: Memcached / central caching >>> >>> Hi, >>> >>> I would like to ask if someone has already investigated or >>> implemented an adapter for OFBiz to use a central caching system like >>> memcached, redis or the like. >>> >>> I know for OFBiz cluster setup there is the distributed cache clear >>> mechanism. >>> >>> I did use that in the past but have found that with more than 2 instances >>> it impacts performance of OFBiz adversely. >>> Symptoms we started to see in production: >>> - We started to see long running transaction locks, General Entity >>> operations slower (might be a combination of load and clustering) >>> - Other idle hosts were 5%-15% busy only to process the cache-clear >>> events without doing anything else >>> - Especially with higher load, the whole thing becomes even slower >>> >>> More load -> More cluster instances -> more cache clear events -> >>> more cycles used to process cache mgmt. -> general >>> requests/operations slower -> so we need even more instances -> you see >>> where it’s going That’s why I was thinking if someone has tried to >>> integrate with a central cache. >>> >>> For single host installation the local in-memory cache is surely >>> faster, even perhaps with a 2host cluster setup, but with 3 or more hosts, >>> I think a central cache might scale better. >>> >>> Also interested to hear about any thoughts on the idea and architecture. >>> >>> Otherwise, any pointers where in the code to look at would be appreciated. >>> I'm thinking to implement it as an adaptor/driver you can switch on if you >>> want it. >>> >>> Thanks >>> Best >>> Leo >>> >>> >> >> >
