Memory footprint of an iRule

Guys - thank you for your replies. Apologies for not responding before now - I need to setup email alerts for this topic!

 

 

Matt - yes, one of the options, for certain types of traffic, is to remove the idle timeout capability from the iRule and have the TCP profile do it. This would mean we would lose other functionality (e.g. checking the total traffic volume) from the iRule, but this may be an option for us for certain types of TCP traffic.

 

 

One thing of note: like I said, my iRule timer monitors the state of the established TCP connection. If it exceeds a configured limit (idle period, total duration or total data volume) the iRule issues a TCP::close command. This works fine in the Standard TCP profile but has no effect when using the Fast L4 TCP profile. Actually I've just found that the "reject" command will terminate an established TCP connection when using the Fast L4 profile; TCP::close will not.

 

 

Colin - yeah, that seems to be the test model we'll have to use. I am not sure how the iRule gets turned into bytecode by the F5; is this only in memory? I guess there's no related disk object that I could check the size of? Even if that did exist, it would probably only include the size of the iRule instructions, not any local variables if these are created on-the-fly during script execution? I'm really clutching at straws here - can you tell? :-)