| Author |
Message
|
| er_pankajgupta84 |
 Posted: Thu Oct 18, 2012 12:47 pm Post subject: |
 |
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Neal - in your scenario you are using broker level HTTP connector/listener so it would be good to raise the maxthread to 750 since your flows are deployed among multiple instances.
But in my scenario I am using EG embedded HTTPConnector so I think the default value of 200 or 250 would be sufficient since I cannot have more than 256 instances running on one EG.
Do you have a clear understanding about 'HTTPListener' -> threadPoolSize and 'HTTPConnector' -> maxThreads at the broker level...how they are different and their use? |
|
| Back to top |
|
 |
| NealM |
| Posted: Thu Oct 18, 2012 2:38 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
| Do you have a clear understanding about 'HTTPListener' -> threadPoolSize and 'HTTPConnector' -> maxThreads at the broker level...how they are different and their use? |
I wish I could say yes. But I cannot. I searched the Apache Tomcat website and of course the IBM documentation without any luck on HTTP or Catalina related thread pool size, always seem to break it down into max threads and max spare threads, which of course is set in the Connector part. Even the WAS infocenter (which unlike the Broker doesn't use Tomcat (wonder why?  )) was no help, just talked about setting a min and max for HTTP/S. So I asked a UK product dev person, and if they ever reply I'll post it here. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Oct 23, 2012 5:43 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Here is what IBM said about # of instances:
"If we start by assuming 20 clients, each client request will "consume" a thread from the (1 per input node + additional instance) thread pool. When the request is received by an HTTPInputNode, a thread is obtained from this pool to service the request, an additional thread is then immediately requested/created ready to service the next request. Each thread will not be released back to the pool until the stack is unwound following completion of the HTTPReply processing. Thus, assuming another client request arrives before the unwinding of the stack, the previously created thread will be obtained from the pool and a new thread created again ready to service the next request. So the broker should use a previously created thread if one is available. but running at respectable transaction rates, you could imagine very quickly reaching the configured limit"
I think this explains why I am seeing 100 instances running even with one user. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 24, 2012 6:36 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
So, here's the complete information from IBM:
'HTTPListener' -> threadPoolSize is, or at least was, an internal setting and thus shouldn't be changed. It is actually now redundant.
Both listeners have HTTPConnector properties; these are the properties that should generally be used for configuration/tuning. Thus, the number of threads should be controlled via the maxThreads property, for both types of HTTP listener. The default, as previously stated, is 200.
Thus,
<Broker Wide> : The component name is httplistener and the objectName is HTTPConnector
e.g. mqsireportproperties <brokerName> -b httplistener -r -o HTTPConnector
<Per Execution Group> : The objectName is HTTPConnector
e.g. mqsireportproperties <brokerName> -e <executionGroupLabel> -r -o HTTPConnector
There is some misleading information in the infocenter relating to HTTPListener properties, including references to threadPoolSize. To avoid confusion, as has been perfectly demonstrated here, I will look to get the applicable infocenter topics updated. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 24, 2012 7:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| And, again, those threads have nothing to do with the instances of a flow. You can potentially see all 200 of those default threads active and running for a flow that only has a single instance. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 24, 2012 8:25 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Is there a limitation on those threads?
I know there is a limitation for # of instance in one EG.
I couldn't connect why 200 threads would be active with just once instance. If you say there could be 200 threads but only 1 of them is active then it make sense to me.
Otherwise, What is the use of number of additional instances property? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 24, 2012 8:32 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| er_pankajgupta84 wrote: |
Is there a limitation on those threads?
I know there is a limitation for # of instance in one EG.
I couldn't connect why 200 threads would be active with just once instance. If you say there could be 200 threads but only 1 of them is active then it make sense to me.
Otherwise, What is the use of number of additional instances property? |
One of the five fundamental topics covered in the IBM Sys Admin course for Broker is
| Quote: |
| Ensuring the efficient operation of a broker |
Have you taken this course? If not, why not? If not, why are you asking us to train you on Ensuring the efficient operation of a broker?
https://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&courseCode=WM643
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Oct 24, 2012 12:12 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Have you taken this course?
if so, can you clarify this doubt?
If not, then please let other help..
My question is pretty straightforward - If broker can keep multiple concurrent active threads for a single instance deployment then what are we specifying by providing additional instances? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Oct 24, 2012 12:26 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| er_pankajgupta84 wrote: |
Have you taken this course?
if so, can you clarify this doubt?
If not, then please let other help..
My question is pretty straightforward - If broker can keep multiple concurrent active threads for a single instance deployment then what are we specifying by providing additional instances? |
You ask too many questions and are high maintenance. Yes, I have taken both the Admin and the Dev courses.
The information you ask about is located in the InfoCentre and in the course material. Do your own research. Don't scam off other's livelihood. Earn your own keep.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| NealM |
| Posted: Wed Oct 24, 2012 1:37 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| the info is also in that developerworks paper that I mentioned and which is (for the most part) still viable. |
|
| Back to top |
|
|
|
|
