| Author |
Message
|
| SureshAlagarsamy |
 Posted: Sun Apr 22, 2007 9:27 pm Post subject: Performance Tuning for webservices |
 |
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
The message flow involves HTTP as Front end interface and has MQ/HTTP as Backend interface decided based on the DB Values.
When posted 120 messages/sec, the flow provides only 70 messages/sec as the Throughput with the cpu utilization consistently being 100%.(Doubt whether the nodes exactly utilizes/waiting makes the cpu 100%).
There were no messages pending in the Broker System.WS.input/reply queue as well. I made some changes in the Tomcat Threads, Aceept count,Heap size which has no effect. The JVMheapsize of the biphttp listener,maxthreads,openfile handles parameter, maxkeepaliverequest parameters were also changed and tested which has also no impact.
Could you suggest me some other ways to get rid of this problem as the Throughput expectation is atleast around 100msg/sec. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Apr 23, 2007 1:06 am Post subject: Re: Performance Tuning for webservices |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| SureshAlagarsamy wrote: |
Could you suggest me some other ways to get rid of this problem as the Throughput expectation is atleast around 100msg/sec. |
How did you arrive at this expectation? Previous testing? Redbook? Did your testing match either the previous configuration or the specified ones?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Apr 23, 2007 1:53 am Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
When I test MQ<-> MQ interface, I am able to get high Throughput around 185msg/sec.
Also in the link "http://www-128.ibm.com/developerworks/websphere/library/techarticles/0608_braithwaite/0608_braithwaite.html?ca=drs- " Throughput has been mentioned around 401msg/sec in Solaris for Webservices.
So I expect atleast 100msg/sec to be processed. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 23, 2007 2:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So when you use MQ<->MQ you get 185 msg/sec.
When you introduce HTTP this drops to 70 msg/sec.
A significant drop.
Again I ask what the 100 msg/sec is based on. If it's just your expectations then I fear your test has proved these expectations optimistic. That's why we performance test.
Does the performance peak at 70 under all circumstances, i.e. if you post 50 msg/sec does it process them all or is there a lag?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Apr 23, 2007 2:44 am Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
This expectation is based on predicted Business requirements.
Yes, the performance peak at 70.When I post 70msg/sec,all th 70 gets processed per second.
The cpu utilization is not consistently 100%.At times it drops down to 85%. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 23, 2007 2:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| SureshAlagarsamy wrote: |
This expectation is based on predicted Business requirements.
|
I always find it amusing when a system is predicted to run at such-and-such a speed "because the business needs it to". I've always found performance is determined more by hardware & software configuration than the business wishing... 
If the performance is consistenly maxed out at 70 m/sec as you describe then clearly there is a bottleneck throtteling it to that speed. This bottleneck does not appear in the MQ<->MQ test and I suspect you've hit a limit in the http code. If the performance had degraded as message speed increased I would have said database contention, but lock collision does not have such a sharp ceiling. Also non-max cpu usage points to network.
You may need to spread the traffic over a number of ports, ensuring each port listener is on a separate thread.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Apr 23, 2007 3:29 am Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
I didn't get you clear.
Currently I have the tomcat configured for a particular port and the MB Support pack deployed in it. My understanding is, this Tomcat port is linked to the flows deployed in a particular message Broker.
Is that possible for a flows deployed in a a Broker to listen for multiple Httplistener ports... |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 23, 2007 3:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I think you'll need to implement it as multiple instances of the flow, each with a promoted port parameter.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Apr 23, 2007 3:55 am Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
Even Currently I have deployed in Multiple Execution Groups,with multiple Additional instances.All the Compiled flows will expose the same url say "/sample/Test" which was mentioned in the Httpinput node properties.
I will post messages using "IP address:tomcat port/sample/Test" which is being cached by the flows deployed across multiple EG's.
How to promote the port number in the flows...Is there any options? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 23, 2007 4:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| SureshAlagarsamy wrote: |
| How to promote the port number in the flows...Is there any options? |
Only to promote or not
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 23, 2007 4:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Each BROKER listens to only one port, every flow that is deployed to it uses that port.
So you can't change the port used by a particular flow or a particular execution group, you can only change the port for the broker.
You can look at the IE01 support pack, it can be very helpful in improving performance for HTTP based broker flows.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Apr 23, 2007 4:54 am Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
| The same IE01 pac is being deployed in Tomcat and used to access HTTP service. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 23, 2007 5:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.
What is the queue manager doing? Is it running out of log space? Which process is using up the CPU during the testing? Is it the DataFlowEngine, or something else?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqseries0209 |
| Posted: Mon Apr 23, 2007 7:13 am Post subject: |
|
|
Voyager
Joined: 30 Mar 2006
Posts: 90
|
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Apr 23, 2007 7:41 pm Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
The DataFlowEngine alone is consuming the CPU when I monitor using prstat command. There is enough disk space when I check using df -k command.
I am not sure about QM logs space....Where I have to look for?
As mentioned in the Link,Somedays back I made the TCPNODELAY parameter to true and tested..which had no impact.
I got an support pack IS02 which would provide performance statistics at nodelevel. But the MQ Explorer version upgrade and Eclipse version upgrade required by the support pac makes it complicated to configure plugin's. |
|
| Back to top |
|
|
|
|
