| Author |
Message
|
| GeneRK4 |
 Posted: Mon Feb 24, 2014 5:09 am Post subject: HTTP concurrent connections to broker |
 |
|
Master
Joined: 08 Jul 2013
Posts: 220
|
I read in IBM document that "maxThreads" is the property which determines the number of concurrent Persistent/Non-persistent HTTP connections to WMB.
My query is if we have 1000 clients concurrently wanting to open persistent connections to WMB,we can set maxThread to 1000.
In this case,should we need to have Number of Additional Instances as 1000 for that flow which has HTTPInput node?
My guess is if we need to set maxThreads as 1000,then we should have 1000 or greater number of additional instances.Please correct if my guess is wrong.. |
|
| Back to top |
|
 |
| Gralgrathor |
| Posted: Mon Feb 24, 2014 10:57 am Post subject: |
|
|
Master
Joined: 23 Jul 2009
Posts: 297
|
I don't think so. After all, incoming HTTP requests are queued on a WMB system queue, and then processed in order of receipt. As long as the EG responding is the same as the one receiving the request, it doesn't matter what instance processes the incoming request - in a timely fashion, of course. The connection is, after all, between client and EG, and not between client and instance.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 24, 2014 2:47 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's not a direct relationship between the number of 'concurrent' HTTP requests and the number of additional instances you need for your flow.
There's also no guarantee that there is any sort of MQ queue between the HTTP listener and the flow node.
IIB/MB gives you lots of options for creating lots of different kinds of HTTP architectures, based on your own local needs and support skills. |
|
| Back to top |
|
|
| GeneRK4 |
| Posted: Wed Feb 26, 2014 6:56 pm Post subject: |
|
|
Master
Joined: 08 Jul 2013
Posts: 220
|
Ok...I can understand that HTTP listener is EG level and the configurations are also done at EG level.So,Max threads of HTTP connections is EG level.
Considering this case,if in a persistent connection where we have set maxthreads=1000,to achieve high scalability,the number of threads (which are flow instances running under an EG) should be equal or greater than this number ...so that all the 1000 HTTP listener instances can be utilised by the flow instances.
Hence...my guess is 1000 instances required to have full utilisation of maxThreads in HTTPListener property.
Please provide your thoughts.. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 26, 2014 10:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| GeneRK4 wrote: |
Ok...I can understand that HTTP listener is EG level and the configurations are also done at EG level.So,Max threads of HTTP connections is EG level.
Considering this case,if in a persistent connection where we have set maxthreads=1000,to achieve high scalability,the number of threads (which are flow instances running under an EG) should be equal or greater than this number ...so that all the 1000 HTTP listener instances can be utilised by the flow instances.
Hence...my guess is 1000 instances required to have full utilisation of maxThreads in HTTPListener property.
Please provide your thoughts.. |
you've already been told that both are two separate things.
They are only related in as such as volume and rate of calls.
Say it takes 500ms to process your call and you have max threads 1,000 and an arrival rate of 2 tps => means no backlog.
If your process rate goes to .2 per second with an arrival rate of 2 tps your queue will be full in about 9 mins...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 13, 2016 6:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
There's also no guarantee that there is any sort of MQ queue between the HTTP listener and the flow node.
|
OK, that was phrased as if you were coached by a lawyer
I knew I wasn't imagining it when I told someone I remember jeff on mqseries.net talking about this topic.
Is there some internal MQ SYSTEM.BROKER.* queue we can monitor that sits in between the HTTP Input Nodes and the biphttplistner?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 13, 2016 6:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| mqjeff wrote: |
There's also no guarantee that there is any sort of MQ queue between the HTTP listener and the flow node.
|
OK, that was phrased as if you were coached by a lawyer
|
| PeterPotkay wrote: |
| I knew I wasn't imagining it when I told someone I remember jeff on mqseries.net talking about this topic. |
If that guy did, I'm sure I don't remember it.
| PeterPotkay wrote: |
| Is there some internal MQ SYSTEM.BROKER.* queue we can monitor that sits in between the HTTP Input Nodes and the biphttplistner? |
There looks to be a couple that are WS.REQUEST and WS.REPLY.
No idea if these are the right queues. Probably a stop/start of the biphttplistener will show that one of these stops having an open input count.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 13, 2016 6:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Just trying to work my way around not knowing how many concurrent HTTP threads we have, as it relates to maxThreads for HTTPPConnector. We use the http listeners at the Execution Group level. I don't see any SYSTEM.BROKER.* queues with Input or Output counts that would correspond with http listeners or http input nodes. Oh well......
Vote for my RFE 
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=92939
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 13, 2016 7:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
EG level http listeners don't use queues.
The biplistener does, because there's one for many EGs. The EG listener doesn't, because there's one for one EG.
The EG level listener is an embedded tomcat. you might be able to use some kind of tomcat monitoring thingy to get the data you want.
Not supported, I'm sure, but.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 13, 2016 3:26 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
thanks for the lead, will check out that path for any possibilities
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
