| Author |
Message
|
| broker_new |
 Posted: Thu Sep 11, 2008 5:59 pm Post subject: Viewing webservice requests |
 |
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
I have nearly 20 message flows that are exposed as web services each webservice calls a stored procedure and waits for significant time and responds with the stored procedure response..
When we are performing a load test on these webservices some requests are getting timed out and i see those requests queueing up in SYSTEM.BROKER.WS.INPUT queue .
I read about the HTTP nodes and each broker by default can accept only 250 concurrent connections is that true.
And we can alter the count using this command..
mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxThreads -v 2000
Could anyone clarify that this is true ............
Is there a way to view what are all the requests that are coming to broker. |
|
| Back to top |
|
 |
| sridhsri |
| Posted: Thu Sep 11, 2008 8:06 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
| Perhaps the problem is that connection between broker and the database is poor - causing the delay. The only way to monitor all requests coming in is to use a tunnel monitor like the one shipped with the toolkit or nettool. |
|
| Back to top |
|
|
| broker_new |
| Posted: Thu Sep 11, 2008 8:13 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Iam wondering how do we achieve it using a nettool or toolkit..
Iam tesing the performance using a JMeter which opens 500 threads and POST for the webservice.
I would like to browse for the requests coming in.....basically for testing the throughput of it.......If it is a simple message flow(MQ protocol) we can do the same using the RFHUTIL utilities(mqputs and mqtimes) |
|
| Back to top |
|
|
| sridhsri |
| Posted: Thu Sep 11, 2008 8:19 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
There is a view in the toolkit called TCPPI Monitor. Nettool has a tab called tunnel monitor. Now that I know you requirement, I am not sure if these tools will help you. I guess you are interested in the time taken for a round trip. The best way is to incorporate that in JMeter or whatever that is. Since it is making the request (and presumably getting the response), it is easiest to calculate the time taken for the round trip from there.
With WMB 6.1, the monitoring profile allows you to log message entry and message exit times for every message. You could leverage this.
p.s: Did you try and increase the number of additional instances on your flows ? |
|
| Back to top |
|
|
| broker_new |
| Posted: Thu Sep 11, 2008 8:25 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
| Actually iam trying to test how many no of concurrent HTTP/HTTPS connections a broker can handle..In the documentation it was said like it can handle max 250 client connections and from 251 connection it should throw Connection refused error but its not happening for me ....using Jmeter i have generated 500 HTTP requests at a given point of time after processing certain number of requests all are getting timedout.. |
|
| Back to top |
|
|
| broker_new |
| Posted: Wed Sep 17, 2008 6:17 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Can anyone answer my query please..... 
I have exposed a webservice which calls the stored procedure ....on the stored procedure end the timeout was set as one minute.
After my performance testing i observed that broker is processing one request at a time.Is that true,does broker can handle concurrent processes...
If i want to accept multiple requests and process them parallely what settings we need to do........... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 17, 2008 7:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| broker_new wrote: |
Can anyone answer my query please.....
I have exposed a webservice which calls the stored procedure ....on the stored procedure end the timeout was set as one minute.
After my performance testing i observed that broker is processing one request at a time.Is that true,does broker can handle concurrent processes...
If i want to accept multiple requests and process them parallely what settings we need to do........... |
Set additional instances of the flow in the bar file. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| broker_new |
| Posted: Wed Sep 17, 2008 8:04 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 17, 2008 8:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And where does it say that it HAS to be processed by a single instance of the flow? Parallelism and throughput are achieved by instanciating more than one instance of the flow in the same execution group. This is done via the additional instances deployment descriptor. It is called scaling.
And for the books the reference to the 250 connections:
| Quote: |
| The default value is 250, which means the 251st client that tries to connect will get a Connection Refused response. (Actually, a few connections in excess of the maxThreads value may be allowed, because connections can be queued up to the limit set by the acceptCount parameter, which is again configurable). In many environments, the default setting may be enough, but in some cases you may need to set this value higher by running this command: mqsichangeproperties MyBroker -b httplistener -o HTTPConnector -n maxThreads -v 2000. (For the meanings of the parameters, see above list.) |
refers to the http listener.
This does not mean that none of them will time out because you do not have enough instances of the flow to handle them in parallel.
This means that should you have an additional client trying to connect to the httplistener it will get a connection refused.
Again, in order to handle the 250 parallel requests you better have an ultra rapid flow and a long timeout on the client or enough instances of the flow to process them in parallel....
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| broker_new |
| Posted: Wed Sep 17, 2008 8:26 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
So broker process each Soap request at a time and while it is processing first message and second request message arrives it will be queued up...
But a webservice deployed in application server behaves differently i dont have the correct number of concurrent process it can handle but it process multiple requests at a particular time... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 17, 2008 8:45 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| broker_new wrote: |
So broker process each Soap request at a time and while it is processing first message and second request message arrives it will be queued up...
But a webservice deployed in application server behaves differently i dont have the correct number of concurrent process it can handle but it process multiple requests at a particular time... |
OK so imagine you have multiple choke points:
- http queue => governed by the httpbiplistener and its configuration
This determines how the listener handles client requests.
- flow input queue => how the httpbiplistener feeds the flow.
- The flow itself with its # of instances.
You can't do much about b) which is determined by a) and c).
Assuming you have 1 instance of the flow only.
Assuming that each instance of the flow will need 1 second in average to process the message
Assuming that you have 200 concurrent requests that will wait for 1 min before timeout...
You can process 60 requests in 1 min. => 140 requests will timeout.
Now with 4 instances of the flow you can process 240 requests in 1 min and none of your requests will timeout.
I think you get the picture now...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Maximreality |
| Posted: Thu Sep 18, 2008 2:39 am Post subject: |
|
|
Acolyte
Joined: 04 Jun 2004
Posts: 65
Location: Copenhagen
|
The biphttplistener supports ~1200 concurrent http connections, if you need more than that you need to put a http proxy in front of the broker.
But as other people has been saying you message flow might need to be instantiated several times to actually provide proper capacity to avoid timeouts.
You also need to configure your biphttplistener correctly if you have a high volume, it very much depends on if you expect many requests from different http clients or many request from the same http client.
You can try this command to disable Nagles Algorithm if you have long response times on a single request
| Code: |
| mqsichangeproperties <BrokerName> -e <ExecutionGroupName> -o ComIbmSocketConnectionManager -n tcpNoDelay -v true |
You should also consider using persistent http connections if you get many requests from the same http client (it can be enabled by setting "Enable HTTP/1.1 keep-alive") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 18, 2008 2:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| The biphttplistener supports ~1200 concurrent http connections, if you need more than that you need to put a http proxy in front of the broker. |
The doc states ~1200 concurrent connections across all flows. This does not mean that you can get more than 250 (max threads) to a single flow in a single execution group. However due to time out wait time and flow speed this may not be relevant.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| broker_new |
| Posted: Thu Sep 18, 2008 8:57 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Iam not clear on one apsect,
If Broker can accept multiple requests(let's say 250) and if it processing one at a time(single threaded) it makes no meaning at all..
We can increase the instances by looking into the memory and no of CPUs available ...This may not be the correct answer because if we increase the Additional instances to 10 and each thread takes atleast 10 seconds to complete the round trip then all the other requests will be queued up anyway and sometimes they may get timedout..........
is it the only way the webservices work ob broker....
Lets take the example of a webservice deployed on application server without increasing no of threads it supports concurrent processing(I dont have correct metrics on that) but i do think this is the limitation on the broker side......
Any thoughts on this |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 18, 2008 9:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Nothing you said in there makes much sense.
When you deploy a J2EE application to a J2EE server, that application is inherently run in many different threads - but that threadpool can be constrained by the app deployment configuration or the app server configuration. That threadpool can only grow to the maximum number of threads that the app server instance can support.
When you deploy a message flow application to a Broekr, that message flow application is inherently run with a single thread per *Input node in the flow. You can configure additional instances of the message flow application, and in 6.1 additional instances for each *Input node, at deploy time. Those additional instances *are* threads, and so it is *the same as* configuring a threadpool in a J2EE app server. You can only run as many additional instances as the ExecutionGroup process will support.
Eveything is Turing complete. It all works "the same way" at a fundamental level. If you use that approach to learning computing technology, it *all* makes sense. There are no Magic Server Beans. |
|
| Back to top |
|
|
|
|
