Author |
Message
|
gakd1987 |
Posted: Wed Jan 06, 2016 10:31 am Post subject: Threading w.r.t HTTPRequest Node |
|
|
Apprentice
Joined: 20 Aug 2013 Posts: 26
|
I have a situation and I need to make sure my thinking goes right.
We have a restful broker flow and we are running 100 instances of this flow in a execution group. There is a layer in the flow where it makes a httpRequest call to the datapower to get a response.
1. First of all I want to make sure that httpRequest node Synchronous . Am I right about this? and thats the reason we have http Asynchronous node provided to us ?
2. If it is synchronous will the behaviour be something like as explained below ?
If we have 50 instances of the flow running and if one of the instances takes 20 secs to get back the response using http Request node then will the rest of 49 requests will wait till it gets chance to use http request node ? or is it that the 50 instacnes of the flow will have 50 instances of httpreuquest which are synchronized as well to run parallely? |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jan 06, 2016 11:00 am Post subject: Re: Threading w.r.t HTTPRequest Node |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
gakd1987 wrote: |
1. First of all I want to make sure that httpRequest node Synchronous . Am I right about this? and thats the reason we have http Asynchronous node provided to us ? |
Yes
gakd1987 wrote: |
2. If it is synchronous will the behaviour be something like as explained below ?
If we have 50 instances of the flow running and if one of the instances takes 20 secs to get back the response using http Request node then will the rest of 49 requests will wait till it gets chance to use http request node ? or is it that the 50 instacnes of the flow will have 50 instances of httpreuquest which are synchronized as well to run parallely? |
The flow "compiles" the nodes into a series of runtime instructions. So each instance of the flow (50 in the example quoted) will make it's own call rather than single threading through a single "http requester".
Note that if all 50 threads are sitting and waiting for 20 seconds to get a response, any new calls to the flow (i.e. a 51st request) will sit and wait at the input node until an instance becomes available. You should scale appropriately. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jan 06, 2016 11:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Well it all depends on how your response part operates.
If there is a single thread servicing all calls, it matters little that you have 50 calls in parallel if they are only being answered serially....
Like Vitor said, you need to scale appropriately...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Jan 06, 2016 11:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You should also really make a lot of performance measurements before you even think about using 50 instances of any flow.
There's almost no chance that you will hit all 50 HTTPRequest nodes at the same time, or even receive 50 input messages at the same time, so there's very little chance of all 50 of those instances being started.
But if they ever do start, you may find that they put an unnecessary burden on the rest of the flows on the machine.
Start with 5. Do testing. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jan 06, 2016 11:13 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fjb_saper wrote: |
Well it all depends on how your response part operates.
If there is a single thread servicing all calls, it matters little that you have 50 calls in parallel if they are only being answered serially.... |
This is a good point. It's not going to matter if you've got 50 separate and distinct requests coming out of IIB if DataPower responds one at a time. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|