Re: Quick questions about f5's iRules

If you want marketing speak-you need me, not Kirk.  ;-)

 

Seriously, you folks have hit upon some of the most basic frustrations that
we at F5 have had concerning iRules since their release-particularly with
the v9.0 upgrade.  Marketing FUD from competitors has obfuscated a couple of
points that Kirk makes; like, the events are always firing and the iRules
engine is always running.  Competitors like to put us in bake-offs and
paid-for testing with "a simple iRule" that they never share in the results
and then comment on how our performance suffers "simply by turning iRules
on".  This is ludicrous, but to people who haven't worked with our gear and
iRules specifically-the numbers say it all.

 

I think I've said it on this list a thousand times-we have a long history at
F5 of giving our customers plenty of rope with which to hang themselves.  It
started with Extended Content Verification (ECV) checks over a decade ago
that allowed you to execute full shell scripts in order to validate the
availability and performance of the server application you were providing HA
for.  This was unparalleled capability at the time (and still beyond some
implementations)-but naturally allowed customers (myself included at the
time) to do some really, really bad things to ourselves, our networks and
our kit. iRules are really no different.  We have provided a fully
extensible and flexible capability to change the very nature of application
delivery that can meet the unforeseen needs of tomorrow, not just today;
that means a lot of ability to break things today.  What was that line from
Spiderman: with great power comes great responsibility??  ;-)

 

So-don't take my word for it.  Don't take Kirk's word for it (although take
his word on this over mine any day).  Go to http://devcentral.f5.com/ and
talk to the people there who make a living doing iRules and iControl.  Write
your iRule and test it for yourself to see how it impacts YOUR application.
If the impact is significant, submit it to DevCentral and see if someone can
provide you some ideas how to optimize it-or maybe even do what you're
trying to do a completely different way.  

 

I know it would be nice if we could just say-yeah, it will hit you by 10
milliseconds-but it's just not that simple.  Even if a single iRule doesn't
have a massive impact, if you run it on every connection and handle Gbps
traffic volumes-it will add up.

 

Great discussion though-and I wish you the best of luck achieving your
solution.

 


KJ (Ken) Salchow, Jr. | Manager, Technical Marketing


D 651.423.1133

M 612.868.1258

P 206.272.5555

F 206.272.5555

 <http://www.f5.com/> www.f5.com

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of
Kirk Bauer
Sent: Thursday, September 10, 2009 9:16 AM
To: Load Balancing Mailing List
Subject: Re: [load balancing] Quick questions about f5's iRules

 

(all of the below is my personal opinion and not any official F5 stance)

 

Of course you are correct, F5 does not and can not guarantee any performance
level with iRules in use.  It completely depends on what the rule does.  As
various other replies have mentioned, we do our best to make the iRule
engine very efficient, we provide timing abilities to help you tune your
iRules, and DevCentral provides a wealth of resources to help you tune
iRules for greater efficiency.  However, if you want to write an iRule that
runs a series of complex mathematical operations on every character in a
512K web page, you can do it, and it will be resource-intensive.

 

Now, for the rest of your questions, I have to mention that I have not seen
the source code for any F5 products so I can't provide you any answers with
100% certainty, but in my understanding:

1)      iRules are pre-compiled so we get by with very little overhead apart
from the actual commands the iRule runs

2)      The iRule engine is always loaded: so going from 0 iRules to 1
simple iRule has minimal impact.  

3)      All of the events already "fire", even if no iRules are attached, so
again adding a simple iRule has minimal impact.

4)      Each connection runs iRules in its own context.  So if you have
10,000 active connections, you have up to 10,000 parallel executions of
iRules.  The rule doesn't have to complete on one connection before it can
run for another.  I would consider this very multi-threaded.

5)      None of our built-in features are done with iRules, however over the
years a number of iRules have been turned into built-in features.  I don't
think we have any performance numbers showing how much performance
increased, but presumably it did increase a little.

 

You make a good point about L7 versus L4 iRules.  In my experience, L4
iRules tend to be very basic and hence extremely fast and efficient.  For
example, this popular iRule is called "Selective SNAT" which basically will
enable SNAT only if the client and the real server are on the same subnet.
This eliminates the common problem of a server hitting its own VIP and then
that other server responding directly to the first server and bypassing the
load balancer.

 

if { [IP::addr [IP::remote_addr] equals [LB::server addr]/16] } {

         snat automap

}

 

The IP::addr command is a built-in command that already does IP/subnet
comparisons very efficiently.  The IP::remote_addr and LB::server_addr are
just hooks into data that is already sitting in memory regarding the
connection.  The "snat automap" is a built-in command to change ourselves to
SNAT mode.  So, effectively, by adding this iRule to a virtual server, you
are doing one IP address comparison that you would not have done if you just
always turned SNAT on.  

If you think of all of the other calculations that are performed to perform
a load balancing decision, this should be a very small percentage in
general.

 

From: [email protected] [mailto:[email protected]] On Behalf Of
Erhan Dolak
Sent: Thursday, September 10, 2009 5:49 AM
To: 'Load Balancing Mailing List'
Subject: Re: [load balancing] Quick questions about f5's iRules

 

Good Day Kirk,

 

I know that most of the vendors does not commit or guaranty the performance
or give any performance figures when scripts are used and surprised about
your comments. Performance has two dependencies, developer brightness and
how the platform handles and executes the code. You may control the second
one only  to commit best performance J

 

From development perspective, it may be very nice if you could give more
detail about how this irules scripts are running on the platform without
breaking your company privacy rules.

 

is there any compilation task to convert the script to machine code before
executing  to achieve the efficiency you described. Also is it possible to
create multithread irules scripts or run it in multithread mode? and last
question, is there any irules used inside F5 by default to accomplish some
basic features defined in the datasheet of the product, so that we can
compare the compiled code and irules performance.

 

I always thought that scripting is the weakest link of this kind of
platforms and any web application. For "web application load balancing", the
execution delay (not the cpu/memory usage) due to scripts can be
understandable and can be seen as part of the web app code but for TCP/UDP
load balancing I always prefer to have functions are available in the
product in enterprise level solution instead of calling a script. Each hook
means delay and resource usage and loading the scripting engine to the
memory. 

 

Regards,

Erhan DOLAK

 

From: [email protected] [mailto:[email protected]] On Behalf Of
Kirk Bauer
Sent: Tuesday, September 08, 2009 8:58 PM
To: Load Balancing Mailing List
Subject: Re: [load balancing] Quick questions about f5's iRules

 

1)      iRules are event-driven which means you can attach iRule code to
various events that already occur in the BIG-IP system.  The standard
full-proxy mode already fires all of these events, whether or not iRules are
being used.  So there is no immediate performance impact just by attaching
an iRule to a virtual server: in other words, the BIG-IP or the specific
virtual sererv will not change modes and become less efficient just because
iRules are being used.  However, there will be some CPU time required to run
the actual iRule code.  This is very efficient, and for most iRules (which
tend to be fairly trivial) the performance impact is negligible.  However,
you can do just about anything you want in an iRule, so it is possible to
significantly affect performance by creating a very intensive iRule.  

2)      There are no published tests because each iRule is different.
However, BIG-IP includes some great timing functionality so you can
determine how much CPU time your iRules utilize, and so you can optimize
your iRule by making changes and observing the effects.

 

From: [email protected] [mailto:[email protected]] On Behalf Of
Joo Yong-Seok
Sent: Tuesday, September 08, 2009 10:46 AM
To: Load Balancing Mailing List
Subject: [load balancing] Quick questions about f5's iRules

 

Hello Load-balancing Gurus,

I have simple questions about f5's iRules. Please share your experience if
you have anything :-)

1) f5's iRule can impact their L4/L7 performance? it means if we're turning
on the options, there is
   any performance degradation or improvement?(maybe upt to iRule script)
2) If there is any official marketing data in regards of iRule test, where
can I get? (like Tolly group
    report).

Thanks in advance.

Best regards,

- yongseok

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki