Author |
Message
|
lancelotlinc |
Posted: Wed Oct 17, 2012 7:49 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
er_pankajgupta84 wrote: |
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? |
Up-to 111 threads. The flow threads won't start till there is a request. Most likely, you will see around ten threads or so with no load on start up. By OS tools, how many threads do you see after start up with no load? _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
er_pankajgupta84 |
Posted: Wed Oct 17, 2012 7:58 am Post subject: |
|
|
 Master
Joined: 14 Nov 2008 Posts: 203 Location: charlotte,NC, USA
|
When my load start I do see more than 100 threads. But this is happening even with the single user which is sending request in a sequential & synchronous mode.
I would expect it to be 12 (based on your analysis) when initial threads are 11 with no load. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 17, 2012 8:10 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
If you feel the behavior of the WMB product is not correct
-AND-
You are on version 7 or later
-AND-
you have attended the requisite training
Quote: |
Requests that are not within the scope of IBM Software Support and require you to contact either your Sales or Professional Services representative: Support for untrained customers: Requests for step by step IBM help but do not have the required IBM product training. IBM Education offers customer training if additional staff training is needed. Please check the IBM Web site for specific information about available courses. |
THEN open a PMR. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
er_pankajgupta84 |
Posted: Wed Oct 17, 2012 8:19 am Post subject: |
|
|
 Master
Joined: 14 Nov 2008 Posts: 203 Location: charlotte,NC, USA
|
Yes, PMR is the next step.
The idea is to get some pointers here to save time from raising a PMR. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 17, 2012 8:21 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
I believe the product is working as designed.
What is the performance concern that is causing doubt for you? _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
er_pankajgupta84 |
Posted: Wed Oct 17, 2012 8:54 am Post subject: |
|
|
 Master
Joined: 14 Nov 2008 Posts: 203 Location: charlotte,NC, USA
|
here is the concern -
If I have a single user which is sending request in a sequential & synchronous mode then despite of the number of additional instances i have defined for the flow, all the messages should be processed by single instance. This is inline with what documentation says.
But If broker is creating 100 instances, which I am seeing in my test, to process those sequentially requests then i am wasting my CPU cycles in schedule threads for processing. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 17, 2012 9:54 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
er_pankajgupta84 wrote: |
If I have a single user which is sending request in a sequential & synchronous mode then despite of the number of additional instances i have defined for the flow, all the messages should be processed by single instance. This is inline with what documentation says. |
Not exactly. The documentation does not say this. The documentation says, with more than one message processing, parallelism is accomplished. A single sequential submission of a string of messages is not guaranteed to get the same thread every time.
er_pankajgupta84 wrote: |
But If broker is creating 100 instances, which I am seeing in my test, to process those sequentially requests then i am wasting my CPU cycles in schedule threads for processing. |
Broker starts all the threads as defined by "additional instances". These are "hot standby".
If concerned about cpu cycles, your client should move off zOS and onto Unix where cpu cycles are not charged back to the cost center.
Hot standby threads (ie. additional instances) on Unix do not consume many meaningful cycles. Therefore, the horsepower is not wasted. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
NealM |
Posted: Wed Oct 17, 2012 9:56 am Post subject: |
|
|
 Master
Joined: 22 Feb 2011 Posts: 230 Location: NC or Utah (depends)
|
1. This would have to be a very, very busy or slow web service to require 100 instances to be available. Note that in Hursley's MB8 HTTP Nodes performance test on zLinux (the only Linux of interest to me at present), Tim had to set the PerformanceHarness for JMS tool to 20 threads firing requests to keep a single instance of his simple flow busy with new messages (your flow is sitting idle in between). His message rate for a 2k (is that ~ your "negligible"?) message was 10,654/sec.
2. What exactly is the Broker wasting? Normally with a web service, a quick response is desirable. In fact, in MB8, you can set your critical flows to be available immediately on Broker startup. And stay available. This is much better than waiting sometimes up to 30 seconds for a normally sub-second webservice that has been fast asleep to wake up and do its job.
3. To see if you are counting your threads correctly, why don't you change your Additional Instances # to 49, then to 199 and count again. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 17, 2012 10:00 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
NealM wrote: |
What exactly is the Broker wasting? |
His client is the largest bank in the US. Client did not purchase Broker, client leases Broker and OS and hardware from IBM, then charges back usage to various cost centers.
Client's complaint is the cost for the lease is too expensive. Client is looking for a way to reduce the cost. They can do this if they find a way to reduce the consumption of CPU cycles, which is how the lease costs are charged back. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
NealM |
Posted: Wed Oct 17, 2012 10:02 am Post subject: |
|
|
 Master
Joined: 22 Feb 2011 Posts: 230 Location: NC or Utah (depends)
|
lancelot, pankaj mentioned linux, not Z/OS. And even if he were on a Z, in running zLinux his CPU would be a cheap IFL, not the big boy. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 17, 2012 10:04 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
NealM wrote: |
lancelot, pankaj mentioned linux, not Z/OS. And even if he were on a Z, in running zLinux his CPU would be a cheap IFL, not the big boy. |
OP can clarify, I believe his dev environment may be Linux but the actual problem is on the Big Iron. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
er_pankajgupta84 |
Posted: Wed Oct 17, 2012 11:10 am Post subject: |
|
|
 Master
Joined: 14 Nov 2008 Posts: 203 Location: charlotte,NC, USA
|
Once again, I am on linux with 7.0.0.4.
Since my response time is 2ms so I am getting 500 TPS with 1 user putting messages in sequence. (So no parallel processing is happening, otherwise i would have got more than 500 TPS)
Now I do agree that I have 100 instances running and the intention is to get close to 500 X 100 TPS with 100 users pushing messages parallel.
If I understood the documentation clearly then if you have multiple instances of a flow running then broker will instantiate new threads/instance only when there is parallel processing.
Is there a deviation to this understanding? Does broker kill the instance every time it process a message and re-create it? |
|
Back to top |
|
 |
NealM |
Posted: Wed Oct 17, 2012 3:19 pm Post subject: |
|
|
 Master
Joined: 22 Feb 2011 Posts: 230 Location: NC or Utah (depends)
|
|
Back to top |
|
 |
er_pankajgupta84 |
Posted: Thu Oct 18, 2012 8:36 am Post subject: |
|
|
 Master
Joined: 14 Nov 2008 Posts: 203 Location: charlotte,NC, USA
|
@Neal - maxKeepAliveRequests parameter will simple tell whether to use the same socket or not. How can it affect number of threads/instances being spanned even with the one user. |
|
Back to top |
|
 |
NealM |
Posted: Thu Oct 18, 2012 8:48 am Post subject: |
|
|
 Master
Joined: 22 Feb 2011 Posts: 230 Location: NC or Utah (depends)
|
Sorry, I was just pointing out what has changed since the WMB v6.0 Broker for which that paper was written. The paper does talk about connections made based on instances, etc, and is still worth reading. And the person who wrote it is on the development group's performance team.
Incidently, for a real world setup, we modify the broker level HTTPConnector values to set maxThreads = 750, maxKeepAliveRequests = -1, tcpNoDelay = true. But we have a DataPower appliance as a load balancer in front of multiple brokers, so since all our webservice messages are coming from one source, keeping the sockets open is efficient.
Regarding that tcpNoDelay setting, look up Nagle's algorithm in wikipedia. |
|
Back to top |
|
 |
|