You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2011/04/21 10:11:37 UTC
Cache in Groovy and Java files
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
Re: Cache in Groovy and Java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <de...@me.com>
> 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" <de...@me.com>
>>> 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" <de...@me.com>
>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: Cache in Groovy and Java files
Posted by David E Jones <de...@me.com>.
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" <de...@me.com>
>> 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" <de...@me.com>
>>>> 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
>>>>>
>>>>>
>>>
>>>
>
>
Re: Cache in Groovy and Java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <de...@me.com>
> 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" <de...@me.com>
>>> 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
>>>>
>>>>
>>
>>
>
Re: Cache in Groovy and Java files
Posted by David E Jones <de...@me.com>.
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
======================
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? What would be the benefit of doing so? What sorts of problems might we cause by doing so?
-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" <de...@me.com>
>> 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
>>>
>>>
>
>
Re: Cache in Groovy and Java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi David,
I have tried to explain my POV a bit more later in the thread.
Jacques
From: "David E Jones" <de...@me.com>
> 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
>>
>>
>
Re: Cache in Groovy and Java files
Posted by David E Jones <de...@me.com>.
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
>
>
Re: Cache in Groovy and Java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
This is a good reminder, but sorry i'ts out of subject ;o)
Even if I replace findByPrimaryKey by findOne (actually findByPrimaryKey simply calls findOne and I agree we should do, there is
still a lot to do in current OOTB code: 1169 instances in Java and Groovy files) I will still wonder why not using findOne with
useCache=true everywhere
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
Do I miss something?
Jacques
From: "Ruth Hoffman" <rh...@aesolves.com>
> Hi Adrian:
> Thanks much for your quick reply.
> Best Regards,
> Ruth
>
> On 4/21/11 11:05 AM, Adrian Crum wrote:
>> From what I recall, there is no difference in functionality. The deprecated methods were merely an effort to simplify the
>> Delegator API.
>>
>> -Adrian
>>
>> On 4/21/2011 8:02 AM, Ruth Hoffman wrote:
>>> Hi Adrian:
>>>
>>> I thought I had seen something like that somewhere. Thanks for the reference. Do you recall if there is someplace that explains
>>> the improvements in findOne over findByPrimaryKey?
>>>
>>> Best Regards,
>>> Ruth
>>>
>>> On 4/21/11 10:57 AM, Adrian Crum wrote:
>>>> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29
>>>>
>>>> -Adrian
>>>>
>>>> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>>>>> Hi Jacques:
>>>>> Out of curiosity, I have often wondered about this:
>>>>> For my own coding, should I use findByPrimaryKey or findOne? Which is the "better" solution? Regardless of Java, Groovy or
>>>>> other?
>>>>> TIA
>>>>> Ruth
>>>>>
>>>>> On 4/21/11 4: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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
Re: Cache in Groovy and Java files
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Adrian:
Thanks much for your quick reply.
Best Regards,
Ruth
On 4/21/11 11:05 AM, Adrian Crum wrote:
> From what I recall, there is no difference in functionality. The
> deprecated methods were merely an effort to simplify the Delegator API.
>
> -Adrian
>
> On 4/21/2011 8:02 AM, Ruth Hoffman wrote:
>> Hi Adrian:
>>
>> I thought I had seen something like that somewhere. Thanks for the
>> reference. Do you recall if there is someplace that explains the
>> improvements in findOne over findByPrimaryKey?
>>
>> Best Regards,
>> Ruth
>>
>> On 4/21/11 10:57 AM, Adrian Crum wrote:
>>> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29
>>>
>>>
>>> -Adrian
>>>
>>> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>>>> Hi Jacques:
>>>> Out of curiosity, I have often wondered about this:
>>>> For my own coding, should I use findByPrimaryKey or findOne? Which
>>>> is the "better" solution? Regardless of Java, Groovy or other?
>>>> TIA
>>>> Ruth
>>>>
>>>> On 4/21/11 4: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
>>>>>
>>>>>
>>>>>
>>>
>
Re: Cache in Groovy and Java files
Posted by Adrian Crum <ad...@sandglass-software.com>.
From what I recall, there is no difference in functionality. The
deprecated methods were merely an effort to simplify the Delegator API.
-Adrian
On 4/21/2011 8:02 AM, Ruth Hoffman wrote:
> Hi Adrian:
>
> I thought I had seen something like that somewhere. Thanks for the
> reference. Do you recall if there is someplace that explains the
> improvements in findOne over findByPrimaryKey?
>
> Best Regards,
> Ruth
>
> On 4/21/11 10:57 AM, Adrian Crum wrote:
>> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29
>>
>>
>> -Adrian
>>
>> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>>> Hi Jacques:
>>> Out of curiosity, I have often wondered about this:
>>> For my own coding, should I use findByPrimaryKey or findOne? Which
>>> is the "better" solution? Regardless of Java, Groovy or other?
>>> TIA
>>> Ruth
>>>
>>> On 4/21/11 4: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
>>>>
>>>>
>>>>
>>
Re: Cache in Groovy and Java files
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Adrian:
I thought I had seen something like that somewhere. Thanks for the
reference. Do you recall if there is someplace that explains the
improvements in findOne over findByPrimaryKey?
Best Regards,
Ruth
On 4/21/11 10:57 AM, Adrian Crum wrote:
> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29
>
>
> -Adrian
>
> On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
>> Hi Jacques:
>> Out of curiosity, I have often wondered about this:
>> For my own coding, should I use findByPrimaryKey or findOne? Which is
>> the "better" solution? Regardless of Java, Groovy or other?
>> TIA
>> Ruth
>>
>> On 4/21/11 4: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
>>>
>>>
>>>
>
Re: Cache in Groovy and Java files
Posted by Adrian Crum <ad...@sandglass-software.com>.
http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/Delegator.html#findByPrimaryKey%28java.lang.String,%20java.util.Map%29
-Adrian
On 4/21/2011 7:52 AM, Ruth Hoffman wrote:
> Hi Jacques:
> Out of curiosity, I have often wondered about this:
> For my own coding, should I use findByPrimaryKey or findOne? Which is
> the "better" solution? Regardless of Java, Groovy or other?
> TIA
> Ruth
>
> On 4/21/11 4: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
>>
>>
>>
Re: Cache in Groovy and Java files
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Jacques:
Out of curiosity, I have often wondered about this:
For my own coding, should I use findByPrimaryKey or findOne? Which is
the "better" solution? Regardless of Java, Groovy or other?
TIA
Ruth
On 4/21/11 4: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
>
>
>