Yes, you are right, I need to get deeper in this, but not at the moment
Jacques
Le 30/10/2014 08:55, Scott Gray a écrit :
Service call or not, the update is still happening in the same transaction at
the same point in the flow. I'd strongly suggest you keep trying your load
tests as I really can't see how anything has changed significantly.
Regards
Scott
On 30/10/2014, at 8:40 pm, Jacques Le Roux <[email protected]> wrote:
I tend to agree, that's why I simply bypassed the service call. Since the
ProductCalculatedInfo is only for recording matter a call after could be a
better solution. For now, I tried to change things as less as possible.
Jacques
Le 30/10/2014 07:35, Scott Gray a écrit :
I have serious doubts there's any significant performance problems with this
simple method. Given this problem occurred during load testing I would be
almost certain that the problem is lock contention on the ProductCalculatedInfo
records.
It's the same old story:
- Long running order creation transaction
- Updating a record that will be touched by many order creation transactions,
causing a lock on the record until the transaction is committed
- The transactions queue up, eventually they have to wait too long and the lock
wait timer runs out or the transaction timeout is hit
The service should be executed in separate transaction after the order
submission transaction is committed.
Regards
Scott
On 30/10/2014, at 7:23 pm, Adrian Crum <[email protected]>
wrote:
Thanks Jacopo.
I noticed the Mini-language service uses two deprecated elements:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+%28minilang%29+Reference
<calculate> should be replaced with <set> and <call-class-method> should be replaced
with <script>.
Perhaps if that service was updated performance would improve.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 10/30/2014 5:57 AM, Jacopo Cappellato wrote:
On Oct 29, 2014, at 8:24 PM, Jacques Le Roux <[email protected]>
wrote:
Apart what I reported in the commit comment and the Jira description, I did not
make other measures. Before it was blocking the JMeter test after it passed.
I suspect that the main difference could be Minilang vs Java, not between
service vs method call: this is why I think it would be interesting to test the
latter (java service vs java method).
We should not switch to direct Java method calls so lightly, at least not
before trying our best to find the root causes (in the service call chain) of
the low performance.
This effort would (if we find the bottleneck in the service call and manage to
fix it) improve the whole system in one shot rather just fixing one service.
Even if the difference is Minilang vs Java, it may be interesting to try to
figure out what is the reason for it (I suspect it could be the larger number
of reflexion) and try to fix it.
I am willing to help you in these tasks but in the meantime I would change you
latest code to use a service call (to Java) rather than a direct method call,
mostly for consistency with the rest of the codebase.
Kind regards,
Jacopo
