If I understand right the issue you are seeing is that some find operations that should be cached are currently not cached. That is most certainly true. Do you have examples of these?
In general with optimization, and use of a cache IS an optimization, it is best to write it using the most clear approach, and then if performance is not acceptable or adequate do profiling and optimization to improve that. Sometimes that optimization might involve caching, and sometimes caching will cause more problems than it will help. I hate writing this over and over, and I'm sure it's in the wiki somewhere, but the mailing list archives are huge and so is the wiki. In general it is best to use a cache when: 1. high read to write ratio (ie read far more often than it is written) 2. likely to be shared among many users If those two aren't the case caching might not be the best idea. Also keep in mind that caches do have a very significant memory footprint. If we cached everything the size of the cache in memory would over time approach the size of the database, and actually because we cache lists of values and not just individual records it could be many many times the size of the database itself. If you want to try this, even with the demo data (ie a small database), try making the few code changes necessary to cache everything and then put a small load on the server, even just in ecommerce with some browsing and order placement, and watch the memory grow. Even if you configured the cache to have size limits, with certain user-specific data elements like the Party* entities and the Order* entities you'll have such a low read to write ratio, partly because of #2 above, that the cache will do as much or more harm than good. If you think this is unreasonable, please do make the case for caching everything. It's certainly an interesting topic to discuss. -David On Apr 21, 2011, at 11:23 AM, Jacques Le Roux wrote: > From: "David E Jones" <[email protected]> >> Do you mean these comments: >> >> ====================== >> I see there is a little overhead in code due to calls to ecaRunner.evalRules >> with EV_CACHE_CHECK/ EV_CACHE_PUT and >> getFromPrimaryKeyCache/putInPrimaryKeyCache when actually the entity is not >> cacheable but it would be largely compensated by real >> use of cache when it's cacheable since it's most cases. To optimize, for the >> cases the entity is not cacheable , we could then later >> replace useCache=true by false >> ====================== > > Yes > >> Those comments address the mechanism of doing so, and one possible issue >> with overhead in a certain configuration, but they don't address the general >> idea of should we really cache everything by default or not. >> >> So what do you think: should we cache everything by default? > > Yes I think so. At least there are a lot of places in OOTB code where Entity > Cache should be used and is not. Maybe it's history, not sure... > >> What would be the benefit of doing so? > > Better performance in most cases. A little overhead after turning to all > cached. Could be easily fixed by checking where not cached Entities are used > and replace there with not cached version of find methods > >> What sorts of problems might we cause by doing so? > > Actually I think that's the question everybody is asking her/himself. This > because of insconsistency in current code where some find should be cached > and are not. I can see only the overhead I noted and it could be easily > avoided, because there are much more cached Entities than not cached. I don't > see any other problems. Maybe I miss something, because I did not went deep > in code, but from a functional POV I don't think so. So a global change to > cached and then local fixes to prevent the overhead is what I'm thinking > about. > > Jacques > > >> -David >> >> >> On Apr 21, 2011, at 10:23 AM, Jacques Le Roux wrote: >> >>> Hi David, >>> >>> I have tried to explain my POV a bit more later in the thread. >>> >>> Jacques >>> >>> From: "David E Jones" <[email protected]> >>>> Jacques, >>>> >>>> Are you proposing that by default we cache all find operations? >>>> >>>> What are the benefits you are hoping for, and the issues you have >>>> considered? >>>> >>>> -David >>>> >>>> >>>> On Apr 21, 2011, at 1:11 AM, Jacques Le Roux wrote: >>>> >>>>> Hi, >>>>> >>>>> It would not be a big work effort to replace,and later use only, all >>>>> findByPrimaryKey, findByAnd and also findList in Groovy and Java files by >>>>> their cache overloads (or useCache for findList). >>>>> Is there a reason it has not been done yet? I can't see one. >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> >>> >>> > >
