| Author |
Message
|
| er_pankajgupta84 |
 Posted: Tue Oct 16, 2012 1:23 pm Post subject: HTTPListener or HTTPConnector or flow instance tuning for WS |
 |
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I have got a simple flow:
HTTPInput -> Compute -> HTTPReply (get an HTTP request & return it as is)
I get a response for an HTTP Request in 2 ms using EG listener for HTTP traffic.
I am running 200 instances of this flow.
With single User I am able to see 500 TPS, where each user is firing next query as soon as it gets back the response of previous request (typically 2 ms)
I would assume that since there is only one user so even though I have 200 instances deployed, only one instance is catering to all the request.
Now since I have 200 instances running of the flow, a simple math will tell that I should be able to achieve 100,000 TPS if I have 200 users firing the HTTP request (provided no CPU utilization bottleneck & memory issues)
Is there anything else that I need to tune to achieve 100,000 TPS with 200 users or 50,000 TPS with 100 users.
Here are some of the properties at the broker level & EG level.
HTTPListener
threadPoolSize=''
HTTPConnector
maxSpareThreads=''
maxThreads=''
minSpareThreads=''
I know the default maxThreads value is 200 but couldn't get the default value for threadPoolSize.
but I think threadPoolSize should not matter in my case since I am using EG level connector instead of broker HTTPListener.
My understanding is the HTTPListener is configured at Broker level and used for both HTTP & SOAP nodes, where as HTTPConnector is configured at the EG level and used for both HTTP & SOAP nodes.
Info-center doesn't represents a clear picture of these.
Any help is appreciated. |
|
| Back to top |
|
 |
| NealM |
| Posted: Tue Oct 16, 2012 2:18 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
| I know the default maxThreads value is 200 but couldn't get the default value for threadPoolSize. |
Isn't ThreadPoolSize just MaxSpareThreads + MaxThreads? So default = 300?
Anyway, if you are going to run with max users = 200, what does it matter?
You didn't mention how long your message is. If you look at any of Tim Dunn's performance reports you will note that indeed, "size matters". And at some length, I would expect a bit of traffic interference to start showing on the port. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Oct 16, 2012 3:26 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
ThreadPoolSize cannot be MaxSpareThreads + MaxThreads since ThreadPoolSize belongs to HTTPListener and other two belongs to HTTPConnector object.
Message size is negligible. |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Oct 17, 2012 1:35 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| I would assume that since there is only one user so even though I have 200 instances deployed, only one instance is catering to all the request. |
Requests are round robbined between ready threads so I would actually expect to see all 200 used; although a single one at a time!
As for your test, I highly suspect you wont see linear performance gains due to constraints previously mentioned (cpu, disk, memory, socket not able to deal with so many concurrent operations). I would just test it rather than hypothesizing what kind of performance you could get. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 17, 2012 3:50 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
256 is the minimum number of thread an EG can start on linux.
Why the documentation says - broker will start another thread only if required despite of how many instances are defined.
If that is true and user is sending message one by one then why multiple threads are created?
Is there a limit on how many connections a socket can handle concurrently?
My aim is not to make a linear assumption but to find a point or limit till when i should see linear results.
Is there any other settings that I need to check to increase thruput of a webservice, other than instances. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 17, 2012 4:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
With HTTP traffic, you need to remember that there's more than one thing in the path of each request.
Particularly if you are not at a version of Broker that supports handlling HTTP requests with the SOAP listener in each EG, there is a set of threads handling HTTP requests in the bipHTTPListener, which is passing messages to each EG where the flow threads are reading them.
So if you have 200 instances of your flow and have left the biphttplistener alone, then you will find that you have very different performance than if you detune the biphttplistener to have only one thread, or tune it to have 100 threads.
And, again, the number of additional instances on a message flow or input node is the *maximum* number of threads that will run simultaneously - based on the number of incoming requests. And requests do not map to end users strictly one to one.
If you have one end user with 200 browser windows open, that's not the same thing as one end user with one browser window open. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 17, 2012 6:03 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I am on 7.0.0.4 on Linux so based on the documentation I can interpret all the requests are reaching to Execution http connector.
The users are visualized in load runner tool.
Another thing that I noticed is even with just one users sending messages sequentially/synchronously i can see multiple threads being instantiated in MB Explorer. I would expect only one thread to be instantiated. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 17, 2012 6:08 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| er_pankajgupta84 wrote: |
| I would expect only one thread to be instantiated. |
Why would you expect this? Thread one processes a request and takes time to die off. There may be many other threads doing other things. WMB engine is not a single thread.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 17, 2012 6:39 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
As per infocenter - "additional threads are created only if there are sufficient input messages. "
Since messages are coming thru HTTP in sequence one after the other so I am expecting one instance to trigger and process all messages.
Note: consider there is only one flow deployed in the EG. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 17, 2012 6:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In order for only one thread to be instantiated and process requests, each request needs to be completed before the next one is submitted.
And, again, even if you have configured the EG to handle incoming HTTP as well as SOAP, and you are referring to the *correct* port after making that configuration, there are still additional threads that handle the HTTP versus the threads that execute the message flow. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 17, 2012 6:55 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| er_pankajgupta84 wrote: |
As per infocenter - "additional threads are created only if there are sufficient input messages. "
Since messages are coming thru HTTP in sequence one after the other so I am expecting one instance to trigger and process all messages.
Note: consider there is only one flow deployed in the EG. |
Additional threads means more threads than are there currently. WMB is not a single threaded application.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 17, 2012 7:01 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
To determine the number of threads used by DataFlowEngine for each message flow:
1. Multiply the number of input nodes by the number of instances (additional threads +1).
2. Sum the values of all message flows, then add 10 to the sum.
3. Add to the sum the number of threads used for each HTTP listener.
WMB can have as many as 11 threads running that are not associated with any message flow. These are administrative overhead threads.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 17, 2012 7:39 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
@Jeff - Yes that is my scenario because my user is firing the second message only when it gets a response to first message.
| Quote: |
| And, again, even if you have configured the EG to handle incoming HTTP as well as SOAP, and you are referring to the *correct* port after making that configuration, there are still additional threads that handle the HTTP versus the threads that execute the message flow. |
My flow just have one input node (HTTP Input).
@lancelotlinc
I was only mentioning application related threads (not broker related threads). I am not sure whether we see broker related threads shows up on MBX.
I have got 1 flow in one EG with 100 instances (i.e with 99 additonal instances) |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 17, 2012 7:42 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| er_pankajgupta84 wrote: |
@Jeff - Yes that is my scenario because my user is firing the second message only when it gets a response to first message.
| Quote: |
| And, again, even if you have configured the EG to handle incoming HTTP as well as SOAP, and you are referring to the *correct* port after making that configuration, there are still additional threads that handle the HTTP versus the threads that execute the message flow. |
My flow just have one input node (HTTP Input).
@lancelotlinc
I was only mentioning application related threads (not broker related threads). I am not sure whether we see broker related threads shows up on MBX.
I have got 1 flow in one EG with 100 instances (i.e with 99 additonal instances) |
Assuming one HTTP listener, this equates to 111 threads. On Unix, use Unix tools to view the threads, not MBX.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 17, 2012 7:45 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
| Quote: |
| Assuming one HTTP listener, this equates to 111 threads. On Unix, use Unix tools to view the threads, not MBX. |
Why?
why should I have 100 threads for my 100 instances when I am not using them at all. Shouldn't it be instantiated when needed? |
|
| Back to top |
|
|
|
|
