Use of pipe in if statement

I'd give it a shot...I know you can use pipe to separate acceptable responses in HTTP monitors...Throw it in and see if you get a syntax error.

Do you mind posting your full code for this? It may be that this could be written into switch statement which would make it more efficient/faster on your BIG-IP.

Thought I had an extra curly brace at the end of the rule I copied in earlier. And maybe I do, but that's not the key here. Still getting a lot of syntax errors stating I need to use curly braces to avoid double substitution. In places that before I added the pipe statement I didn't need to use before.

Wow, a lot of logic there... What are you accomplishing with the above iRule?

Posted By iRuleYou on 08/24/2010 08:31 AM

 

Wow, a lot of logic there... What are you accomplishing with the above iRule?

 

 

Round robin load balancing of Diameter messages. Unfortunately, because of the need to do a little bit more than just a simple RR LB, such as changing the Origin Host on responses from the server, the iRule is needed instead of just using the Diameter profile. Lab testing found that the max supportable TPS was about 10,500 on a 6900 running 10.1. With more clients, and attention paid to even client distribution across the TMM's, we could probably push that higher, since 15 Seagull clients running concurrently for a total of 8500 TPS had the total CPU load a little over 70%. This iRule does introduce a load hit on the CPU, and a rather significant load at that.

As far as the beast above, I noticed that you're doing a lot of setting statics and math in the CLIENT_ACCEPTED event that could be done in RULE_INIT rather than for every single connection. Is there a reason for that?

 

 

 

For instance all of this code could easily be moved to RULE_INIT where it would be run once at load time, rather than for every single connection. Unless I'm missing something, these are all static values that are either being set or computations based on static values that could be set once and then left alone...right?

 

 

     set maxloop 20 
     set timeout 11100 
     set DWA_head 010000400000011800000000 
     set DWA_avp 0000010c4000000c000007d1000001084000000e4249472d495000000000012840000010746573742e636f6d 
     set DPA_head 0100004c0000011a00000000 
     set DPA_avp 0000010c4000000c000007d1000001084000000e4249472d495000000000012840000010746573742e636f6d0000010c4000000c000007d1 
     set ohostval "lb.site.com" 
     set ohostdlen [string len $ohostval] 
     set ohostlen {expr $ohostdlen + 8} 
     set ohostpad {expr (4 - ( ${ohostdlen} % 4) )%4 } 
     set ohostlen_pad {expr $ohostlen + $ohostpad } 
     set my_ohostavp {binary format IIa${ohostdlen}H[expr 2 * ${ohostpad}] 264 [expr (0x40<<24)| ${ohostlen}] $ohostval 000000} 
     binary scan $my_ohostavp H* ohosthex 
 
  

 

 

That's an immense amount of overhead that you could carve out of each connection with about 30 seconds worth of changes to variable names and one new EVENT declaration.

 

 

Just a thought.

 

 

Colin

Posted By Colin Walker on 08/25/2010 03:02 PM

 

As far as the beast above, I noticed that you're doing a lot of setting statics and math in the CLIENT_ACCEPTED event that could be done in RULE_INIT rather than for every single connection. Is there a reason for that?

 

 

 

For instance all of this code could easily be moved to RULE_INIT where it would be run once at load time, rather than for every single connection. Unless I'm missing something, these are all static values that are either being set or computations based on static values that could be set once and then left alone...right?

 

 

     set maxloop 20 
     set timeout 11100 
     set DWA_head 010000400000011800000000 
     set DWA_avp 0000010c4000000c000007d1000001084000000e4249472d495000000000012840000010746573742e636f6d 
     set DPA_head 0100004c0000011a00000000 
     set DPA_avp 0000010c4000000c000007d1000001084000000e4249472d495000000000012840000010746573742e636f6d0000010c4000000c000007d1 
     set ohostval "lb.site.com" 
     set ohostdlen [string len $ohostval] 
     set ohostlen {expr $ohostdlen + 8} 
     set ohostpad {expr (4 - ( ${ohostdlen} % 4) )%4 } 
     set ohostlen_pad {expr $ohostlen + $ohostpad } 
     set my_ohostavp {binary format IIa${ohostdlen}H[expr 2 * ${ohostpad}] 264 [expr (0x40<<24)| ${ohostlen}] $ohostval 000000} 
     binary scan $my_ohostavp H* ohosthex 
 
  

 

 

That's an immense amount of overhead that you could carve out of each connection with about 30 seconds worth of changes to variable names and one new EVENT declaration.

 

 

Just a thought.

 

 

Colin

 

 

I'll be honest, this is just what was presented to me, so I'm not sure what the reasoning was to put all this into the CLIENT_ACCEPTED. Assuming that all connections get the default settings, if that mass can be moved to a better location, I'm all for it. As I mentioned in the thread, the overhead on this was pretty shocking. More efficiency is always appreciated.

Thanks for the "static::my_ohostavp" pointer. Would have missed that one right off.

 

 

I did go through and incorporate some switch statements in a few locations. So far, so good. Haven't tested the functionality yet, but once we do, I'll post some stats. I'me very curious to see what the differences look like.

 

 

-eaw

The first thing I notice is that in the RULE_INIT section you'll want to use the static::var form as well.

 

 

So set ohostval "lb.site.com" becomes set static::ohostval "lb.site.com"

 

 

 

Other than that though, looks good, assuming you didn't change anything other than moving that chunk up into RULE_INIT

 

 

Colin

Took a while, but finally got enough numbers to deem them useful. Here's the stats comparison between the version using switch and moving items to RULE_INIT vs. the original.

 

 

 

SwitchTotalFailAbortMinAvgMax

 

CLIENT_ACCEPTED800275223684644352

 

CLIENT _CLOSED40073802001620016

 

CLIENT_DATA811001482753843901069785

 

LB_FAILED000000

 

RULE_INIT000000

 

SERVER_CLOSED14001116550612240

 

SERVER_CONNECTED220062822512851138

 

SERVER_DATA46260041175222773468693

 

 

 

OriginalTotalFailAbortMinAvgMax

 

CLIENT_ACCEPTED400168291183235199242

 

CLIENT _CLOSED40058591994419944

 

CLIENT_DATA68210115632309014830115

 

LB_FAILED000000

 

SERVER_CLOSED150099958017920

 

SERVER_CONNECTED130099542989648987

 

SERVER_DATA28756044289221750341775

 

 

Looks like a HUGE savings in CLIENT_ACCEPTED, as predicted, but CLIENT_DATA and CLIENT _CLOSED appear to have increased a bit. Overall, if you take a summation of everything, there is still an overall savings happening.

 

 

I don't know if this is a really great representation, as we were more testing to check the functionality when passing AVP 309, which never seemed to happen in the first place (d'OH!), so I made the best of a fairly busted situation.