Forum Discussion

simon_irwin_849's avatar
Icon for Nimbostratus rankNimbostratus
Jan 24, 2011

Memory footprint of an iRule

Hi guys -



Is there any way to tell how much memory an iRule requires to maintain a given TCP connection?



Here's my scenario:



- i have a TCP virtual server with an associated iRule


- the iRule is quite long and relatively complex; among other things, it wakes up every 30 seconds or so to check the status of the connection (e.g. inactivity and data thresholds).



Load testing is indicating that the iRule adds an extra 10kb to each TCP connection (I think it was 4K without the iRule, 14K with the iRule). This seems to be an average when 100,000s of simultaneous connections are used. I think tmstat was used to measure this.



My question is whether a developer has ready access to the amount of memory required for a single connection. I want to be able to tweak the iRule and see the memory requirements drop (hopefully!) so I can make informed decisions about what looks worth changing.



any help would be gratefully received






5 Replies

  • Simon: have you considered using the native TCP profile timeouts to manage that portion of this rule? It may be possible to optimize that a bit via native mechanisms as opposed to doing it all within the iRule.



    Obviously I'm making assumptions about the use case that may not be accurate...



  • Colin_Walker_12's avatar
    Historic F5 Account



    There is no command within iRules to display or make decisions upon the memory usage of a single connection. That being said the tools on the system are designed to show you overall memory usage, not specific per con mem usage, as far as I am aware. This is something you could conceivably script via iControl, but there isn't anything out of the box that I can think if that will break out memory used per connection for you. The closest you could get would be to set up a controlled VIP where you set up your config and fire a steady xCPS at it then view the average memory usage for that VIP and base your calculations on that.



  • 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? :-)
  • Colin_Walker_12's avatar
    Historic F5 Account
    Hah, I love your thought process, it's right on the money. Unfortunately you're completely correct. Even if you could get at the byte code it wouldn't give you an accurate depiction of the entirety of the memory footprint. Your best bet is going to be to do some polling.



  • Thanks, Colin. We've been running our load tests to try to measure where the best gains in RAM are. Reducing the use of local variables has been the biggest help so far.



    I also have the following kind of code:





    set myVar {


    <20-30 lines of script>





    catch { if 1 $myVar}





    I used "myVar" as a kind of macro and invoked it 4 times in my iRule. Load tests showed that it was better (lower RAM usage) just to replicate the block of 20-30 lines throughout the iRule, as opposed to using my macro, even though "myVar" *should* be turned into bytecode.



    Thanks for the responses to this thread.