| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Http Proxy Servlet in Production (and active-active cluster) |
« View previous topic :: View next topic » |
| Author |
Message
|
| hopsala |
 Posted: Sun May 22, 2011 6:18 am Post subject: Http Proxy Servlet in Production (and active-active cluster) |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Hey there,
I'm trying to decide whether to use the Http Proxy Servlet (HPS) or the WMB 7 native listeners. The way I see it, the main issues are:
1. HPS uses one port. Native listeners (SOAP) are one port per EG, which restricts flow deployment to a particular EG, otherwise consumers have to change URLs.
2. HPS communicates with the broker using MQ queues. I'm not sure whether this is a disadvantage or a benefit. I wonder what the performance implications are.
3. HPS requires a servlet container, WAS or other, which means another license, configuration, monitoring, another point of failure etc.
4. The literature states that HPS doesn't work with multi-instance QMs. However, I can configure two WAS servers, each with an instance of the HPS; each HPS will be configured to load balance webservice traffic to both brokers, so that if one crashes, the other takes over. Unless I'm wrong, this way I get a perfectly viable active-active setup.
I'm not that keen on using the HPS, unless I find good reaso to do so. I can get load balacing capabilities using the on-site dedicated load balancer. Are there any other considerations I'm missing? Anyone has any experience with the HPS in production environment, clustered or otherwise?
Cheers!  |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon May 23, 2011 3:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Even if you restrict flow deployment to a specific EG, you still end up having multiple URLS for the clients, unless you are at version 7 and can configure the HTTP nodes to use the EG level listener rather than the bipHTTPListener.
Also remember that while the ProxyServlet does require a servlet container, that container can easily be an open source servlet container, depending on your site policies. So that at least helps with the license issue. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed May 25, 2011 1:38 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
| Even if you restrict flow deployment to a specific EG, you still end up having multiple URLS for the clients, unless you are at version 7 and can configure the HTTP nodes to use the EG level listener rather than the bipHTTPListener. |
I'm at V7. Since the broker hosts a variety of HTTP and SOAP nodes I think it's best I stick to the EG listeners for both HTTP and SOAP. What I meant was that if a flow runs on EG1 for a while, and I'm working with an EG level listener, I can't just deploy it to EG2 - I have to let the consumers know. Or, if I have a load balancer, I have to configure it appropriately.
I'm not sure what the reprecussions are to having a broker working with both the biplistener and the eg listeners - it's one more thing to remember in a prod environment, which I'd rather avoid, but is there some other gotcha involved?
| mqjeff wrote: |
| Also remember that while the ProxyServlet does require a servlet container, that container can easily be an open source servlet container, depending on your site policies. So that at least helps with the license issue. |
True, but using an open source servlet container might not give me the ability to map urls to cerificates, concerning our other discussion.. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed May 25, 2011 1:39 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Ok, so let me put my question another way - If I have a load balancer, is there any reason to use the Http Proxy Servlet? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 25, 2011 8:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hopsala wrote: |
| Ok, so let me put my question another way - If I have a load balancer, is there any reason to use the Http Proxy Servlet? |
If I remember well what I read the answer for this is volume and response times... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu May 26, 2011 2:11 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fjb_saper wrote: |
| If I remember well what I read the answer for this is volume and response times... |
Well, there's this in the lit:
| Quote: |
| "By using the HTTP proxy servlet in an external web servlet container, you can support a larger number of concurrent HTTP sessions, high availability, load distribution, and access to the broker from multiple IP addresses and ports." |
But no specifics. Do you have a reference? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 26, 2011 2:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hopsala wrote: |
| fjb_saper wrote: |
| If I remember well what I read the answer for this is volume and response times... |
Well, there's this in the lit:
| Quote: |
| "By using the HTTP proxy servlet in an external web servlet container, you can support a larger number of concurrent HTTP sessions, high availability, load distribution, and access to the broker from multiple IP addresses and ports." |
But no specifics. Do you have a reference? |
No. No specifics. The passage you're quoting in the lit was what I was referring to. As I understand it the main difference is that the servlet is putting the message to some internal queue and then the broker picks it up.
The tasks assigned by the servlet don't have to be done by the broker any more.
As well an app server is better equipped to handle concurrency (in the 2000 + requests than the broker which, if memory serves well, is said to top out at about 900 to 1000 according to lit?
Deploying the servlet to a front end farm you could potentially hit way more concurrent requests...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon May 30, 2011 10:52 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fjb_saper wrote: |
No. No specifics. The passage you're quoting in the lit was what I was referring to. As I understand it the main difference is that the servlet is putting the message to some internal queue and then the broker picks it up.
The tasks assigned by the servlet don't have to be done by the broker any more. |
Yep, I've seen this in action many times. The servlet writes to an internal broker queue, the EGs get it and reply to another queue; it works exactly like the biphttplistener. This means there should be some degradation in performance, as you've got an additional component - the queue - in between; and if you're not careful in the way you configure this queue, you've got quite a lot of logging IO on your hands..
| fjb_saper wrote: |
As well an app server is better equipped to handle concurrency (in the 2000 + requests than the broker which, if memory serves well, is said to top out at about 900 to 1000 according to lit?
Deploying the servlet to a front end farm you could potentially hit way more concurrent requests...
Have fun |
You're probably right. Although overall performance might be lower due to MQ acting as mediator, concurrent session handling should be significantly better. However, I wonder how this affects timeout processing - I have the sneaking suspicion that the servlet is part of the reason we have so many socket timeouts here..
I've been emailing with one of the developers from the WMB team, and he pretty much said that if I already have a load balancer, and I don't need URL/cert mapping (see http://www.mqseries.net/phpBB2/viewtopic.php?p=304535) then there's no reason to use the proxy servlet. He hasn't replied to my question about performance yet, we'll see if he has something more definite to say about this. Thanks! |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
