Author |
Message
|
IIB_Intel |
Posted: Fri May 12, 2017 7:54 am Post subject: HTTP 1.1 vs HTTP 1.0 in IIB v9 |
|
|
Acolyte
Joined: 07 May 2015 Posts: 64
|
Has someone used Http 1.1 with "keepaliveCOnnection" in IIB v9 over HTTP 1.0. Do you see performance improvement with that?
We are facing some performance issues with occasional spike in the response time.
The overall system is a combination of services communicating XML/HTTPS. We have enabled monitoring on flows and what we have observed is that requests from one flow to the other flow taking a delay of 50-500 ms occasionally.
This time gap is the time elapsed between HTTPRequest.Terminal.In of one flow and Transaction.Start of the other flow.
There could be 2 reasons (that I know off) for this.
1. Creation of new HTTP connection taking time. So we were thinking of changing property on HttpRequest node to use Http 1.1. Just wanted some experience/thoughts here?
2. Additional instance is required to process that particular request (the one that shows the spike) and IIB is taking time to create the new thread. Since over load is not that much < 5 TPS, I doubt this could be a reason as broker will create a new instance the moment all other become active.
Could there be any other reason, that we should think of?
Please note we use EG http/https listener and we have defined sufficient number of instances and maxThreadPool is set to 400 which is less than the total number of instances of all the flows in that EG.
Memory & CPU looks ok at the time of spikes and we are on IIB 9.0.0.5 on linux. The expected response time is 500-700 ms and we are acheiving that 85% of the time, its just that remaining 10-15% of the time response time varies from 1-10 seconds. |
|
Back to top |
|
 |
zpat |
Posted: Fri May 12, 2017 8:17 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
As with everything, using MQ would be the best protocol and communication between flows using a local queue manager should be very fast. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
IIB_Intel |
Posted: Fri May 12, 2017 2:23 pm Post subject: |
|
|
Acolyte
Joined: 07 May 2015 Posts: 64
|
yeah, agree but the current problem in hand is for http. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri May 12, 2017 10:17 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
IIB_Intel wrote: |
yeah, agree but the current problem in hand is for http. |
Use Http 1.1. It will save you the time of building the connection each time. At 5 tps you should see an improvement.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
IIB_Intel |
Posted: Mon May 15, 2017 6:20 am Post subject: |
|
|
Acolyte
Joined: 07 May 2015 Posts: 64
|
Any other parameter (other than the ones I mentioned in my original post) that could contribute to time gap between HTTPRequest.Terminal.In of one flow and Transaction.Start of the other flow (which is invoked by the HTTpRequest node)? |
|
Back to top |
|
 |
zpat |
Posted: Mon May 15, 2017 7:52 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
IIB_Intel wrote: |
yeah, agree but the current problem in hand is for http. |
So get involved at the design stage to avoid this sort of problem. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
IIB_Intel |
Posted: Mon May 15, 2017 8:52 am Post subject: |
|
|
Acolyte
Joined: 07 May 2015 Posts: 64
|
The solution involved has composite services and individual micro-services are also called from outside. Using MQ is not an option here.  |
|
Back to top |
|
 |
|