Author |
Message
|
akil |
Posted: Fri Nov 14, 2014 10:03 am Post subject: IIB9: httpasyncrequest or additional instances ? |
|
|
 Partisan
Joined: 27 May 2014 Posts: 338 Location: Mumbai
|
Hi
How does one decide between the following
1) increasing additional instances of a flow that has a the simple ( blocking ) http request node
2) converting the flow to use httpasyncrequest and reducing additional instances?
I have a scenario where a flow makes one http call ( the http call takes 7-8 seconds to complete ) & the input throughput is 10 requests per minute.. _________________ Regards |
|
Back to top |
|
 |
smdavies99 |
Posted: Sat Nov 15, 2014 12:15 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
How does one decide?
Lots and lots and lots of testing. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
akil |
Posted: Sat Nov 15, 2014 10:35 am Post subject: |
|
|
 Partisan
Joined: 27 May 2014 Posts: 338 Location: Mumbai
|
What should I be looking for in the tests?
As I understand, either of the 2 approaches will have threads blocking for the hTTP request to complete, it'll either be a thread that processes the message flow (in case of HTTPRequest) , or a broker background thread (in case of HTTPAsyncRequest)..
What are the parameters to consider/ in play here? _________________ Regards |
|
Back to top |
|
 |
ruimadaleno |
Posted: Wed Nov 19, 2014 8:09 am Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
How many requests this flow will receive ?? what are the SLA for the service response.
If the service has "low usage" (it's your call to define , under your environment , what is "low usage") you can go for additional instances , but have in mind that each additional instance means additional threads => more memory usage => more processing for thread handling
if the service has a "high usage" and you can modify it to make it work in a async fashion (use a queue to gather all requests "quickly", consume the requests, and sent the response latter)
in fact there is no "magic number" nor "golden rule" here, it's all about your message flow, business requirements and SLA's ... test .. test test .. and test it  _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
akil |
Posted: Wed Nov 19, 2014 10:43 am Post subject: |
|
|
 Partisan
Joined: 27 May 2014 Posts: 338 Location: Mumbai
|
Since http is synchronous , a thread will get created even if I use httpasyncrequest isn't it? So the choice is between the message flow thread or some background thread created by the broker for every httpasyncrequest call that gets made .. _________________ Regards |
|
Back to top |
|
 |
mgk |
Posted: Wed Nov 19, 2014 11:28 am Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
With the HTTP Async nodes, we only create one background thread to handle all Async Requests with a given node pair.
Another point to consider is that in the Async case, the response is processed in a different transaction to the request.
Kind regards, _________________ MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
Back to top |
|
 |
ruimadaleno |
Posted: Thu Nov 20, 2014 1:31 am Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
Hi Akil,
from what i'm reading in this post:
message flow "diagram":
flow start ---> some nodes ---> http request --> some nodes --> flow end
each http request takes 7-8 seconds
message flow receives 10 requests/minute
Goal: (what are you trying to achieve ) increase message flow response time ? _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
akil |
Posted: Fri Nov 21, 2014 4:32 am Post subject: |
|
|
 Partisan
Joined: 27 May 2014 Posts: 338 Location: Mumbai
|
trying to reduce response time, with just 1 thread, the 10th request takes 100 seconds .. if i make additional instances 10, each request takes 10 seconds ..
I was wondering if I should just do that or invest in re-creating the message flows and doing http-async-request .
With 2 message flows , there are 2 transactions, and some additional work to transfer the context, handling 2 time outs , so it is a fair about of refactoring ..
If it was a 100 concurrent request scenario, I would not have asked this question, i would have started the refactoring, but with around 10 requests, am wondering if i just run with the additional threads, and watch out for something _________________ Regards |
|
Back to top |
|
 |
ruimadaleno |
Posted: Fri Nov 21, 2014 7:26 am Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
why does your flow takes 10 seconds to complete it's work ? where is this time "wasted" ? can it be improved ? _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
akil |
Posted: Fri Nov 21, 2014 6:22 pm Post subject: |
|
|
 Partisan
Joined: 27 May 2014 Posts: 338 Location: Mumbai
|
The http request takes up that time, this request goes over the internet over to a service provider and back.. _________________ Regards |
|
Back to top |
|
 |
ruimadaleno |
Posted: Mon Nov 24, 2014 1:54 am Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
Hi akil, so you are stuck with that service provider
Increasing additional instances doesn't allow you to run the message flow faster, it allows you to handle more requests/executions of the flow in parallel.
With 0 (zero) additional instances, you get only one thread to handle requests. When one request arrives it is handled by this thread to process message. Meanwhile, if a second request arrives, it will wait until the first request is fully processed, this wait time will be something like 10 seconds (it's the time you message flows needs to complete his work, including the call to external provider).
So , increasing additional instances will allow you to handle more requests simultaneously, for the end user it will be see as a performance improvement because you can process requests in a parallel fashion.
Real performance improvement can only by achived by "fixing" the external provider service.
You can also modify the message flow to use async requests, but this will modify the usage of the message flow (think: if you process in an async fashion, how does you message flow consumers know wich response corresponds to a given request) _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
|