David,
Thanks for your feedback and sorry, indeed your answer makes totally sense, I
should have had a look before in the MLs.
The cases which are interesting me are when they should be cached and are not OOTB. I finally agree with you that blindly
generalizing
could be worse than letting as is (premature optimization). I notably missed
the point about sharing among users. I went that way
because I'm working on a site where there will be very few products with plenty
of memory on web app servers but much less (still
fairly decent) on DB servers. I definitively need to have a closer look...
I have though already some examples which could be interesting to cache, even
OOTB, notably in Groovy scripts. Of course not with
thousands of products, though, even then, OFBiz users could go the other way:
see where there is too much cache memory usage and
adjust locally. I could have given more details but it would have been too long
and I think Entities names are enough at this stage.
This is mostly from Groovy scripts in ecommerce and ordermgnr (not exhaustive)
, those entities are cacheable.
Product
ProductFeature
ProductCategoryMember
ProductPromo
ProductFeatureAndAppl
ProductStoreSurveyAppl
MimeType
Enumeration
ContactList
ContactMechPurposeType
PartyContentType
ShipmentMethodType
ReturnType
ReturnReason
ReturnItemTypeMap
Jacques
From: "David E Jones" <[email protected]>
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
