Performance problem with balanceInventoryItems service

[Adrian Crum-2]

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



     

[Adam Heath-2]

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.

[Adrian Crum-2]

Thanks Adam! That was one of the things I was considering. ;-)

-Adrian


--- On Fri, 10/31/08, Adam Heath <[hidden email]> wrote:

> From: Adam Heath <[hidden email]>
> Subject: Re: Performance problem with balanceInventoryItems service
> To: [hidden email]
> 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.

     

[Adrian Crum-2]

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 <[hidden email]> wrote:

> From: Adam Heath <[hidden email]>
> Subject: Re: Performance problem with balanceInventoryItems service
> To: [hidden email]
> 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.

     

[David E Jones]

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 <[hidden email]> wrote:
>
>> From: Adam Heath <[hidden email]>
>> Subject: Re: Performance problem with balanceInventoryItems service
>> To: [hidden email]
>> 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.
>
>
>