• 2 replies
  • Latest Post - ‏2013-04-26T19:22:39Z by JoeMorganNTST
172 Posts

Pinned topic Max number of handlers per MPG, WSP, XML Firewall

‏2013-04-26T13:36:32Z | - max mpg numbers wsp xml

1.)Max number of handlers per MPG, WSP, XML Firewall. Any recomondation on this number ?


2.)Max number WSDL 's can be attached to  WSP ?


3.)Impact of single entry point DMZ routing service?  on a long run will it hurt.. are there any recomondations for limiting number callers per service ? or number of concurrent calls. After two years if this service end up as entry point for 2000 URL's doesnt it have any impact on performance or box shut down issues.


4.) Please add urs max numbers if u have a personal preference?

  • kenhygh
    2474 Posts

    Re: Max number of handlers per MPG, WSP, XML Firewall


    1) I'm not aware of any upper limit. You want to keep this number as small as possible just because of the management overhead. A typical number is 1.

    2) I'm not aware of any upper limit. You want to keep this number as small as makes sense, again for maintainability. If you have a lot of WSDLs that are always deployed together and versioned together, they might better belong in a single WSDL.

    3) Obviously, the more load you put on a box, the more CPU and memory will be consumed. It's typical to have either a load-balancer or using DataPower's AO self-balancing to have multiple machines in a tier. 2000 URLs by itself means little. Peak TPS, message size, backend latency are more important numbers.


  • JoeMorganNTST
    427 Posts

    Re: Max number of handlers per MPG, WSP, XML Firewall


    1) "Handlers"?  Are you talking about front side handlers.  For XMLFW, it is 1.  For MPG and WSP, I've never used more than a few, so never tried to test the limit.  If "Handlers" refers to rules in a processing policy, I've seen many, many rules in a policy, and again, don't have the upper limit. 

    2) I know I have a single WSP with 22 WSDLs, so it handles that many.  I wouldn't generally recommend this approach, but I'm doing this for a complex versioning solution.   One thing to note on this approach... when you update something for a single operation or something that maybe applies to just one of them, you'll be restarting the *whole* thing, meaning you'll have some downtime on all of them (But I generally find it pretty quick).  I also recently experienced an issue where a problem in one WSDL seemed to take down the whole thing.  So, if you have 20 WSDLs aggregated under a single WSP, you might be endangering the servicing of the others for the problems of one.

    3) This is wide open, and only you can answer some of this.  For DMZ routing service, if "long runs" can be posted to a messaging service, you likely don't need so much worry about it.  That's an architectural question, though, and impossible to answer.  For limiting the number of callers per service, you can setup count monitors and define the thresholds for throttling.  You can define more than one count monitor per service, so you have a lot of control.  For the last question on this, what are you planning to do?  Is there a better solution?  That is, do you really need to handle 2000 URLs, or are there groups of them having the same dynamic back end?  Matching actions for a processing rule can be very complex.

    One thing to keep in mind... just because you *can* do something doesn't mean you *should* do something.   Also, use your monitoring tools.  Of course there is a limit to the processing capabilities, and you'll need to informatively know when your appliance will be taxed.  I assume you will do load testing? 

    Also, know your appliance.  You didn't mention what appliance(s) you have.