You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@yahoo.com> on 2008/11/01 01:28:46 UTC
Performance problem with balanceInventoryItems service
I have a client who has asked me to look into the performance problem with the balanceInventoryItems service. I see from the commit logs that it has been a problem for others too - David mentions it in the rev 576793 commit log.
I'd like to get this fixed in the trunk. If anyone has any ideas on ways to improve it, please let me know. I have some ideas of my own. Maybe together we can get this fixed.
-Adrian
Re: Performance problem with balanceInventoryItems service
Posted by David E Jones <jo...@hotwaxmedia.com>.
The cache would only help if the same data, unchanged, is accessed
over and over, so it may not be helpful for this situation, and like
you said especially in a distributed environment (even with
distributed cache clear setup) it could cause problems.
-David
On Nov 1, 2008, at 2:34 PM, Adrian Crum wrote:
> I have the view entity working for the outer loop. I still have the
> PicklistAndBinAndItem entity-condition because the service is
> looking for an empty list being returned (no records found). I don't
> know if view entities support something like that.
>
> I haven't enabled the cache on the new view entity because I'm not
> sure if it is a wise thing to do. How would concurrency affect the
> returned values? In other words, in a very busy environment with
> clustered servers working on the same database, are we sure the
> returned values are accurate?
>
> -Adrian
>
> --- On Fri, 10/31/08, Adam Heath <do...@brainfood.com> wrote:
>
>> From: Adam Heath <do...@brainfood.com>
>> Subject: Re: Performance problem with balanceInventoryItems service
>> To: dev@ofbiz.apache.org
>> Date: Friday, October 31, 2008, 7:31 PM
>> Adrian Crum wrote:
>>> I have a client who has asked me to look into the
>> performance problem with the balanceInventoryItems service.
>> I see from the commit logs that it has been a problem for
>> others too - David mentions it in the rev 576793 commit log.
>>>
>>> I'd like to get this fixed in the trunk. If anyone
>> has any ideas on ways to improve it, please let me know. I
>> have some ideas of my own. Maybe together we can get this
>> fixed.
>>
>> Hmm, outer query, loop over results, inner getRelated,
>> second nested
>> inner loop, and none of this cached.
>>
>> Yup, perfect candidate for a View.
>>
>> ps: Hint, a View can contain nested Views. IE, a
>> member-entity can
>> point to a view itself.
>
>
>
Re: Performance problem with balanceInventoryItems service
Posted by Adrian Crum <ad...@yahoo.com>.
I have the view entity working for the outer loop. I still have the PicklistAndBinAndItem entity-condition because the service is looking for an empty list being returned (no records found). I don't know if view entities support something like that.
I haven't enabled the cache on the new view entity because I'm not sure if it is a wise thing to do. How would concurrency affect the returned values? In other words, in a very busy environment with clustered servers working on the same database, are we sure the returned values are accurate?
-Adrian
--- On Fri, 10/31/08, Adam Heath <do...@brainfood.com> wrote:
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: Performance problem with balanceInventoryItems service
> To: dev@ofbiz.apache.org
> Date: Friday, October 31, 2008, 7:31 PM
> Adrian Crum wrote:
> > I have a client who has asked me to look into the
> performance problem with the balanceInventoryItems service.
> I see from the commit logs that it has been a problem for
> others too - David mentions it in the rev 576793 commit log.
> >
> > I'd like to get this fixed in the trunk. If anyone
> has any ideas on ways to improve it, please let me know. I
> have some ideas of my own. Maybe together we can get this
> fixed.
>
> Hmm, outer query, loop over results, inner getRelated,
> second nested
> inner loop, and none of this cached.
>
> Yup, perfect candidate for a View.
>
> ps: Hint, a View can contain nested Views. IE, a
> member-entity can
> point to a view itself.
Re: Performance problem with balanceInventoryItems service
Posted by Adrian Crum <ad...@yahoo.com>.
Thanks Adam! That was one of the things I was considering. ;-)
-Adrian
--- On Fri, 10/31/08, Adam Heath <do...@brainfood.com> wrote:
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: Performance problem with balanceInventoryItems service
> To: dev@ofbiz.apache.org
> Date: Friday, October 31, 2008, 7:31 PM
> Adrian Crum wrote:
> > I have a client who has asked me to look into the
> performance problem with the balanceInventoryItems service.
> I see from the commit logs that it has been a problem for
> others too - David mentions it in the rev 576793 commit log.
> >
> > I'd like to get this fixed in the trunk. If anyone
> has any ideas on ways to improve it, please let me know. I
> have some ideas of my own. Maybe together we can get this
> fixed.
>
> Hmm, outer query, loop over results, inner getRelated,
> second nested
> inner loop, and none of this cached.
>
> Yup, perfect candidate for a View.
>
> ps: Hint, a View can contain nested Views. IE, a
> member-entity can
> point to a view itself.
Re: Performance problem with balanceInventoryItems service
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> I have a client who has asked me to look into the performance problem with the balanceInventoryItems service. I see from the commit logs that it has been a problem for others too - David mentions it in the rev 576793 commit log.
>
> I'd like to get this fixed in the trunk. If anyone has any ideas on ways to improve it, please let me know. I have some ideas of my own. Maybe together we can get this fixed.
Hmm, outer query, loop over results, inner getRelated, second nested
inner loop, and none of this cached.
Yup, perfect candidate for a View.
ps: Hint, a View can contain nested Views. IE, a member-entity can
point to a view itself.