Forum Discussion

Kai_Wilke's avatar
Oct 12, 2015

Question on EVAL

Hi Folks,

 

i'm wondering what the side effects are if you do that...

 

when RULE_INIT priority 10 {
    set static::code_blob1 [b64decode "....64kbyte of Code...."]
}

when RULE_INIT priority 20 {
    set static::code_blob2 [b64decode "....64kbyte of Code...."]
}

when RULE_INIT priority 30 {
    set static::code_blob_combined "$static::code_blob1$static::code_blob1"
    unset -nocomplain static::code_blob1
    unset -nocomplain static::code_blob2
}

when HTTP_REQUEST {
    eval $static::code_blob_combined    
}

Could this coding technique be used as an additional workaround for SOL9204? (https://support.f5.com/kb/en-us/solutions/public/9000/200/sol9204.html)

 

My current experience is that the combined CODE blob would become a single TCL_Obj which would be shared across different TCP connections within a single TMM. In addition the code gets byte-compiled on the very first execution (independently on each TMM) and subsequent executions (on same or different connections) would experience only a very little CPU overhead for the additional execution of the EVAL command and variable access on the static:: namespace.

 

Any thoughts?

 

Cheers, Kai

 

2 Replies

  • good question, really no idea, but is getting around the 64k limit the only thing you are looking for? aren't multiple irules not an option?
  • Hi Boneyard,

     

    you’re right. My initial posting consisted two independent questions in one... ;-)

     

    1.) Does the outlined coding technique have serious TMM side effects (e.g. massive memory consumption on each connection) compared to regular iRules?

     

    2.) Would it be still “safe to use” if the code gets bigger than 64k?

     

    Well, the code base on our production environments is already spanning multiple iRules and each additional iRule produces some overhead to check the results from previous iRules. So the workaround of chaining multiple iRules is unfortunately not that ideal…

     

    And the 64k limit is indeed not the only reason why I’m currently interested in evaling static:: variables. In addition I have also noticed that the contained TCL code does not follow the limitations of SOL13253. The code could be modified/optimized (even by itself), then become byte-compiled again on the very next execution and then affects every established connection pointing to this code structure. So configuration changes will become active at your fingertips...

     

    There are also some additional possibilities to further optimize the code structures. Below are a few examples of the things I’ve currently in my mind to optimize the execution of the evaled code structures.

     

    1.) Perform a complete substitution of static:: configuration values during RULE_INIT and not on every consecutive connection/request.

     

    2.) Evaluate “if $static::x …” or “switch $static::x …” configuration decisions during RULE_INIT. Basically you could change a string, a single TCL command, an entire line, a code block or even an entire code path on the fly based on configuration variables, datagroups or tcl lists without evaluating the config on every connection/request. If the global configuration variables are changed, make sure to flush the caches and rebuild the code structure right after...

     

    3.) Create runtime generated, highly optimized code paths for consecutive request based on a combination of well-known runtime variables / array elements without using a rather complex "foreach" iteration or multiple “if …” or “switch …” decisions.

     

    4.) Precompile entire code structures by resolving, iterating and chaining TCL code blocks fetched from procedure outputs (e.g via return {body}) . It’s a kind of procedure based coding style without calling a procedure at runtime - its some sort of TCL macro'ing. By doing so a code can become as granular as a developer can think of without scarifying overall performance due to repeated calling of procedures and executing code or mapping variables across different runtime levels.

     

    5.) Time will tell... throwin some sideband connections and even background/garbage collection tasks to maintain the cached code structures and let your mind flow...

     

    Cheers, Kai