| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| HttpListener Threadpoolsize and instances of HTTP msg flows |
« View previous topic :: View next topic » |
| Author |
Message
|
| raghubegur |
 Posted: Fri Sep 22, 2006 12:34 pm Post subject: HttpListener Threadpoolsize and instances of HTTP msg flows |
 |
|
Apprentice
Joined: 15 Jul 2002
Posts: 45
|
Hi,
Can someone tell me which of the following would be a optimal solution to improve message throughput when I have http message flows deployed.
1) multiple instances of http message flows
2) increasing the HTTPListener threadPoolSize
3) Both --> please tell me how 1) and 2) are related
Further, how does 'Supportpac IE01 Proxy Servlet for HTTP nodes' fit into my requirement to increase throughput ?
The HTTP threads block waiting for responses from the HTTPReply nodes. Is there a way to minimise / eliminate this blocking time
Cheers,
Raghu |
|
| Back to top |
|
 |
| aq |
| Posted: Mon Sep 25, 2006 2:31 am Post subject: |
|
|
Apprentice
Joined: 20 Dec 2001
Posts: 47
|
> .. improve message throughput when I have http message flows deployed
>1) multiple instances of http message flows
>2) increasing the HTTPListener threadPoolSize
>3) Both --> please tell me how 1) and 2) are related
You didn't mentioned, but I assume you mean by "http message flows" mostly HTTPInput flows ?
Depends the situation, but ultimately both ...
The HTTPListener and http message flow instances are related roughly like this:
http-request --> HTTPListener --MQPUT--> SYSTEM.BROKER.WS.INPUT --MQGET--> HTTPInput-MessageFlow
1) multiple instances of specific (HTTPInput) flows have more threads that read HTTP-MQ messages from SYSTEM.BROKER.WS.INPUT queue that HTTPListener threads have put there. Increasing instances increase concurrent message handling capacity of this specific message flow.
If flow instances are not already increased from the default one, then increasing this would give the best increase in throughput.
2) This affects of how many HTTPListener threads there are to receive concurrent HTTP-requests ("mini web server" of the broker). Increasing HTTPListener threads affect all message flows (more HTTP input => more messages in SYSTEM.BROKER.WS.INPUT queue for the message flows).
If all HTTPListener threads are in use (for example 50) and there comes 51 HTTP-request connection attempt, I think the client in those cases receives some network connection error ("connection refused" or such).
> how does 'Supportpac IE01 Proxy Servlet for HTTP nodes' fit into my requirement to increase throughput ?
You can implement your own HTTPListener, instead of using brokers. You would use this for example in situation when you want to increase concurrent http-request handling (broker can receive http-requests, but "real" web application server probably can receive more concurrent requests). So if receiving concurrent http-requests is or becomes problem even after increasing the HTTPListener threads from the default value, then this might future option.
> HTTP threads block waiting for responses from the HTTPReply nodes. Is there a way to minimise / eliminate this blocking time
I could be wrong, but I think there is not (except processing the messages faster  or changing the design to 2-way HTTP-communications) because in the background there are those open client socket connections from http-requests. But if there is a way I' am also interested to know about it 
ps. My knowledge is from WBIMB 5, so some things might be different and more improved in WMB 6 version ... |
|
| Back to top |
|
|
| raghubegur |
| Posted: Mon Sep 25, 2006 7:27 am Post subject: |
|
|
Apprentice
Joined: 15 Jul 2002
Posts: 45
|
Hi AQ,
Thanks for your inputs.
What does '2-way communications' mean ?
Here is a simplistic representation of my request and response message flows. Is this what you mean ? :
Request : HttpInput -> process msg -> store httprequestid -> MQOutput.
Response : MQInput -> process msg -> retrieve httpreqestid -> HTTPReply.
So it is the HTTP 'Listener' threads that block and wait for responses from the HTTPReply nodes, not the message flow threads itself. Is this correct understanding ?
Thanks,
Raghu |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon Sep 25, 2006 8:41 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi raghubegur,
| raghubegur wrote: |
| So it is the HTTP 'Listener' threads that block and wait for responses from the HTTPReply nodes, not the message flow threads itself. Is this correct understanding ? |
Yes thats correct...the port is not a one single opening....when a HTTP Request runs, a logical port is opened(and remains open even though the request flow/thread is over), and closed when the reply is completed...atleast thats my understanding
Regards. |
|
| Back to top |
|
|
| aq |
| Posted: Mon Sep 25, 2006 9:05 pm Post subject: |
|
|
Apprentice
Joined: 20 Dec 2001
Posts: 47
|
| raghubegur wrote: |
| What does '2-way communications' mean ? |
Bad and too short explanation I guess... well shortly I mean this:
Request : HttpInput -> process msg -> store replyToURL -> MQOutput -> HTTPReply (just HTTP 200 OK)
Response : MQInput -> process msg -> retrieve replyToURL -> HTTPRequest
Async. http / WS-addressing (http://www.w3.org/Submission/ws-addressing/) where the request maker client tells replyTo URL-address in request where to send / make http-request when reply is ready. This would minimize the time that those threads / sockets / logical ports are kept open by HTTPListener for http-requests, but of course this would also mean more logic to implement in client, and it would probably work best is scenarios where the communication can be asynchronous (not so well for example when there is actual person waiting on client side for quick http-reply from broker). |
|
| Back to top |
|
|
| raghubegur |
| Posted: Wed Sep 27, 2006 12:34 pm Post subject: |
|
|
Apprentice
Joined: 15 Jul 2002
Posts: 45
|
Hi,
The default value for the HTTPListener thread pool is 50.
Is this a static number ?
Or does the count actually start at 1 and go up as and when the input message volume rises ? ( limited by the max value of 50 ).
Thanks,
Raghu |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
