Irule for 4.6.1

First of all, there is no "daemon" parsing iRules in v4.x. Complex rules (like yours) may really cause high latency.

 

 

To be able to suggest how to optimize your rule, I'd need to have detailed description of how you actually want to route your requests. In theory it is possible to reverse engineer this from your rule, but it is a) time consuming b) works only if I can assume that your rule currently implements exactly the necessary behavior.

 

 

Here are some general iRule optimization techniques:

 

 

* if possible avoid destination address or server name matching and replace it with unique virtual server which of course requires that there is unique address,

 

* if unique addresses for sites are not an option, use redirection to unique port specific virtual servers for each site (see example bellow),

 

* put the most likely matches (e.g. the most frequently visited URIs) at the top,

 

* hierarchically decompose your rule by matching common conditions first and do additional matching in the body of the higher level rule (you do that in your rule already ... but maybe you can do more of that :-)),

 

* use class matching instead of if-then-else chains wherever possible,

 

* cluster matches resulting in the same action (i.e. selection of the same pool),

 

 

Example of redirection to port specific virtual based on the "Host" header in the request:

 

 

rule host_switch {
   if(http_host == "www.palgrave-journals.com") {
      redirect to "http://www.palgrave-journals.com:81" + http_uri
   }
   else if(http_host == "www.nature.com") {
      redirect to "http://www.nature.com:82" + http_uri
   } else if( .... }
rule palgrave {
  
}
rule nature {
  
}
...
virtual :80 {
   use rule host_switch
}
virtual :81 {
   use rule palgrave
}
virtual :82 {
   use rule nature
}
...

 

 

The example assumes that DNS names (www.nature.com et. al) for all of your sites resolve to the same IP address (denoted above). I've checked couple of them and it seems to be the case.

 

 

Caveats:

 

 

* using other TCP port than 80 for HTTP traffic is suboptimal because some cheaper (e.g. stateless) and/or misconfigured firewalls may block the traffic. Also some cheap (read: braindead) IDSes may flag the traffic as suspect,

 

* if your web applications contain many absolute references (i.e. including the host part of the URI) it may actually end-up being slower than the one-common-rule approach,

 

 

The above decomposition should speed up rule matching in your case despite certain level of duplication of "rule code" in individual "per-site" rules. The main speed-up is comes from the fact that the "host_switch" rule is consulted only once per client visit and majority of current HTTP clients and servers support persistent (keep-alive) connections (however see caveat 2 above which may spoil the trick). The per-site rules are still going to be evaluated on each HTTP request (assuming that you have global variable "web parse" set to "all" [the default] in your configuration) but they should be shorter than your current one-for-all rule and hence quicker to evaluate.

 

 

As allways YMMV :-).