| Author |
Message
|
| nagarjun_vv |
 Posted: Fri Jun 12, 2015 12:10 am Post subject: Performance Test on message flow : Inconsistency in results |
 |
|
Apprentice
Joined: 24 Jun 2008
Posts: 33
|
Hi,
We are performing load test of 500 transactions for a service. The service reqeust flow accepts soap message from queue, read data from Cache(shared row loaded once from DB), transform message into fixed length message and send to Backend.
The service response flow accepts message from backend and again transform as per Consumer expected response and send to Consumer.
Problem :- When we fire transaction one by one, then Request flow and response flow each take approx. 1 millisecond as their processing time. However when we perform load test with 0 additional instances, then few transactions(5%) will take close to 1 second instead of 1-2 millisecond which rest(95%) are taking. Request and response messages are same for all transactions.
Expectation :- As seen, there is no consistency in the processing time, we are looking processing time of approx 1 ms for all transactions(including thsoe 5%).
Please suggest some solution for this problem.
Thanks |
|
| Back to top |
|
 |
| McueMart |
| Posted: Fri Jun 12, 2015 1:01 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
As with all performance testing, your first task is to determine where the issue is (Is it in your tool which sends the request? Is it a network issue? Is it a DB issue? Is it something slow in the code? Is it due to resource contention on the Machine? etc etc).
For this I would recommend you enable User Trace. From that you can hopefully see where abouts in the code (if it is in the code...) that this 1 second delay is occurring.
Once you have tracked down the source of the performance issue, you can then start tackling the cause. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Jun 12, 2015 2:39 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I'd probably start by modifying the flow to simulate the backend connection just to eliminate that from the equation.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 12, 2015 4:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smdavies99 wrote: |
| I'd probably start by modifying the flow to simulate the backend connection just to eliminate that from the equation. |
Wouldn't node level statistics highlight the problem if it was the back end system? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ganesh |
| Posted: Fri Jun 12, 2015 9:37 am Post subject: Re: Performance Test on message flow : Inconsistency in resu |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| nagarjun_vv wrote: |
Hi,
We are performing load test of 500 transactions for a service.
Problem :- However when we perform load test with 0 additional instances, then few transactions(5%) will take close to 1 second instead of 1-2 millisecond which rest(95%) are taking.
Thanks |
You could try increasing the additional instances on the flow and see if there is a change in the behavior. |
|
| Back to top |
|
|
| nagarjun_vv |
| Posted: Sun Jun 14, 2015 9:59 pm Post subject: |
|
|
Apprentice
Joined: 24 Jun 2008
Posts: 33
|
Hi,
1)We are using jmeter to do performance testing.
2) We have removed backend and used stub also to test, but still same behaviour.
3) We are hitting a servlet(which receives request from tool) which is responsbile to post message to the input queue of reqeust message flow.
4) We have checked and there is no DB loading again and again. Once Cache is loaded, subsequent transactios are using Cache data only.
5) We have avoided datasource connectivity also for these subsequent transactions as they are fetching from cache only.
6) We have tried increasing additional instances to 5 and test, still same behaviour.
7) When tested for 1-1 transaction, processing time is 1 millisecond by request flow and response flow each. Hence No code issue.
 Change the transaction mode at mqinput node to 'No' and rest 4 Mqoutput nodes to 'Automatic', still same behaviour.
9) Increse the commit count at bar file level to 5 and till 20 also, still same. However not sure how exactly commit count works.
10) Machine and execution group is ok as the Java code with same functionality is working fine.
Please suggest. |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Jun 15, 2015 12:27 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I already did - see my first post.
Take a UserTrace. Look at the timestamps in it. Look for any large jumps in time. Figure out what's causing it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 15, 2015 4:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| nagarjun_vv wrote: |
7) When tested for 1-1 transaction, processing time is 1 millisecond by request flow and response flow each. Hence No code issue.
Please suggest. |
I take this to mean you are using asynchronous nodes.
The problem may not be in your code but have you considered the resource response time?
Say request flow time and response flow times are consistent... what happens to the times in between?
Also a pause from time to time makes me think about garbage collection. What can you tell us about that?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 15, 2015 4:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
With a single instance, you are limited to the amount of messages that can be processed in a given amount of time. This includes the number of messages you can send out simultaneously and the number of messages you can process simultaneously.
Since the request consumer is reading messages from a queue, you should monitor the queue depth and the count of the messages being read and the time taken to read each message. If the reply is also going to a queue, then the same (for the put and the get). |
|
| Back to top |
|
|
|
|
