Advanced iRules: An Abstract View of iRules with the Tcl Bytecode Disassembler
In case you didn't already know, I'm a child of the 70's. As such, my formative years were in the 80's, where the music and movies were synthesized and super cheesy. Short Circuit was one of those cheesy movies, featuring Ally Sheedy, Steve Guttenberg, and Johnny Five, the tank-treaded laser-wielding robot with feelings and self awareness. Oh yeah! The plot...doesn't at all matter, but Johnny's big fear once reaching self actualization was being disassembled. Well, in this article, we won't dissamble Johnny Five, but we will take a look at disassembling some Tcl code and talk about optimizations. Tcl forms the foundation of several code environments on BIG-IP: iRules, iCall, tmsh, and iApps. The latter environments don't carry the burden of performance that iRules do, so efficiency isn't as big a concern. When we speak at conferences, we often commit some time to cover code optimization techniques due to the impactful nature of applying an iRule to live traffic. This isn't to say that the system isn't highly tuned and optimized already, it's just important not to introduce any more impact than is absolutely necessary to carry out purpose. In iRules, you can turn timing on to see the impact of an iRule, and in the Tcl shell (tclsh) you can use the time command. These are ultimately the best tools to see what the impact is going to be from a performance perspective. But if you want to see what the Tcl interpreter is actually doing from an instruction standpoint, well, you will need to disassemble the code. I've looked at bytecode in some of the python scripts I've written, but I wasn't aware of a way to do that in Tcl. I found a thread on stack that indicated it was possible, and after probing a little further was given a solution. This doesn't work in Tcl 8.4, which is what the BIG-IP uses, but it does work on 8.5+ so if you have a linux box with 8.5+ you're good to go. Note that there are variances from version to version that could absolutely change the way the interpreter works, so understand that this is an just an exercise in discovery. Solution 1 Fire up tclsh and then grab a piece of code. For simplicity, I'll use two forms of a simple math problem. The first is using the expr command to evaluate 3 times 4, and the second is the same math problem, but wraps the evaluation with curly brackets. The command that will show how the interpreter works its magic is tcl::unsupported::disassemble. ## ## unwrapped expression ## ## % tcl::unsupported::disassemble script { expr 3 * 4 } ByteCode 0x0x1e1ee20, refCt 1, epoch 16, interp 0x0x1d59670 (epoch 16) Source " expr 3 * 4 " Cmds 1, src 12, inst 14, litObjs 4, aux 0, stkDepth 5, code/src 0.00 Commands 1: 1: pc 0-12, src 1-11 Command 1: "expr 3 * 4 " (0) push1 0 # "3" (2) push1 1 # " " (4) push1 2 # "*" (6) push1 1 # " " (8) push1 3 # "4" (10) concat1 5 (12) exprStk (13) done ## ## wrapped expression ## ## % tcl::unsupported::disassemble script { expr { 3 * 4 } } ByteCode 0x0x1de7a40, refCt 1, epoch 16, interp 0x0x1d59670 (epoch 16) Source " expr { 3 * 4 } " Cmds 1, src 16, inst 3, litObjs 1, aux 0, stkDepth 1, code/src 0.00 Commands 1: 1: pc 0-1, src 1-15 Command 1: "expr { 3 * 4 } " (0) push1 0 # "12" (2) done Because the first expression is unwrapped, the interpreter has to build the expression and then call the runtime expression engine, resulting in 4 objects and a stack depth of 5. With the wrapped expression, the interpreter found a compile-time constant and used that directly, resulting in 1 object and a stack depth of 1 as well. Much thanks to Donal Fellows on Stack Overflow for the details. Using the time command in the shell, you can see that wrapping the expression results in a wildly more efficient experience. % time { expr 3 * 4 } 100000 1.02325 microseconds per iteration % time { expr {3*4} } 100000 0.07945 microseconds per iteration Solution 2 I was looking in earnest for some explanatory information for the bytecode fields displayed with tcl::unsupported::disassemble, and came across a couple pages on the Tcl wiki, one building on the other. Combining the pertinent sections of code from each page results in this script you can paste into tclsh: namespace eval tcl::unsupported {namespace export assemble} namespace import tcl::unsupported::assemble rename assemble asm interp alias {} disasm {} ::tcl::unsupported::disassemble proc aproc {name argl body args} { proc $name $argl $body set res [disasm proc $name] if {"-x" in $args} { set res [list proc $name $argl [list asm [dis2asm $res]]] eval $res } return $res } proc dis2asm body { set fstart " push -1; store @p; pop " set fstep " incrImm @p +1;load @l;load @p listIndex;store @i;pop load @l;listLength;lt " set res "" set wait "" set jumptargets {} set lines [split $body \n] foreach line $lines { ;#-- pass 1: collect jump targets if [regexp {\# pc (\d+)} $line -> pc] {lappend jumptargets $pc} } set lineno 0 foreach line $lines { ;#-- pass 2: do the rest incr lineno set line [string trim $line] if {$line eq ""} continue set code "" if {[regexp {slot (\d+), (.+)} $line -> number descr]} { set slot($number) $descr } elseif {[regexp {data=.+loop=%v(\d+)} $line -> ptr]} { #got ptr, carry on } elseif {[regexp {it%v(\d+).+\[%v(\d+)\]} $line -> copy number]} { set loopvar [lindex $slot($number) end] if {$wait ne ""} { set map [list @p $ptr @i $loopvar @l $copy] set code [string map $map $fstart] append res "\n $code ;# $wait" set wait "" } } elseif {[regexp {^ *\((\d+)\) (.+)} $line -> pc instr]} { if {$pc in $jumptargets} {append res "\n label L$pc;"} if {[regexp {(.+)#(.+)} $instr -> instr comment]} { set arg [list [lindex $comment end]] if [string match jump* $instr] {set arg L$arg} } else {set arg ""} set instr0 [normalize [lindex $instr 0]] switch -- $instr0 { concat - invokeStk {set arg [lindex $instr end]} incrImm {set arg [list $arg [lindex $instr end]]} } set code "$instr0 $arg" switch -- $instr0 { done { if {$lineno < [llength $lines]-2} { set code "jump Done" } else {set code ""} } startCommand {set code ""} foreach_start {set wait $line; continue} foreach_step {set code [string map $map $fstep]} } append res "\n [format %-24s $code] ;# $line" } } append res "\n label Done;\n" return $res } proc normalize instr { regsub {\d+$} $instr "" instr ;# strip off trailing length indicator set instr [string map { loadScalar load nop "" storeScalar store incrScalar1Imm incrImm } $instr] return $instr } Now that the script source is in place, you can test the two expressions we tested in solution 1. The output is very similar, however, there is less diagnostic information to go with the bytecode instructions. Still, the instructions are consistent between the two solutions. The difference here is that after "building" the proc, you can execute it, shown below each aproc expression. % aproc f x { expr 3 * 4 } -x proc f x {asm { push 3 ;# (0) push1 0 # "3" push { } ;# (2) push1 1 # " " push * ;# (4) push1 2 # "*" push { } ;# (6) push1 1 # " " push 4 ;# (8) push1 3 # "4" concat 5 ;# (10) concat1 5 exprStk ;# (12) exprStk ;# (13) done label Done; }} % f x 12 % aproc f x { expr { 3 * 4 } } -x proc f x {asm { push 12 ;# (0) push1 0 # "12" ;# (2) done label Done; }} % f x 12 Deeper Down the Rabbit Hole Will the internet explode if I switch metaphors from bad 80's movie to literary classic? I guess we'll find out. Simple comparisons are interesting, but now that we're peeling back the layers, let's look at something a little more complicated like a for loop and a list append. % tcl::unsupported::disassemble script { for { $x } { $x < 50 } { incr x } { lappend mylist $x } } ByteCode 0x0x2479d30, refCt 1, epoch 16, interp 0x0x23ef670 (epoch 16) Source " for { $x } { $x < 50 } { incr x } { lappend mylist $x " Cmds 4, src 57, inst 43, litObjs 5, aux 0, stkDepth 3, code/src 0.00 Exception ranges 2, depth 1: 0: level 0, loop, pc 8-16, continue 18, break 40 1: level 0, loop, pc 18-30, continue -1, break 40 Commands 4: 1: pc 0-41, src 1-56 2: pc 0-4, src 7-9 3: pc 8-16, src 37-54 4: pc 18-30, src 26-32 Command 1: "for { $x } { $x < 50 } { incr x } { lappend mylist $x }" Command 2: "$x " (0) push1 0 # "x" (2) loadStk (3) invokeStk1 1 (5) pop (6) jump1 +26 # pc 32 Command 3: "lappend mylist $x " (8) push1 1 # "lappend" (10) push1 2 # "mylist" (12) push1 0 # "x" (14) loadStk (15) invokeStk1 3 (17) pop Command 4: "incr x " (18) startCommand +13 1 # next cmd at pc 31 (27) push1 0 # "x" (29) incrStkImm +1 (31) pop (32) push1 0 # "x" (34) loadStk (35) push1 3 # "50" (37) lt (38) jumpTrue1 -30 # pc 8 (40) push1 4 # "" (42) done You'll notice that there are four commands in this code. The for loop, the x variable evaluation, the lappend operations, and the loop control with the incr command. There are a lot more instructions in this code, with jump pointers from the x interpretation to the incr statement, the less than comparison, then a jump to the list append. Wrapping Up I went through an exercise years ago to see how far I could minimize the Solaris kernel before it stopped working. I personally got down into the twenties before the system was unusable, but I think the record was somewhere south of 15. So...what's the point? Minimal for minimal's sake is not the point. Meet the functional objectives, that is job one. But then start tuning. Less is more. Less objects. Less stack depth. Less instantiation. Reviewing bytecode is good for that, and is possible with the native Tcl code. However, it is still important to test the code performance, as relying on bytecode objects and stack depth alone is not a good idea. For example, if we look at the bytecode differences with matching an IP address, there is no discernable difference from Tcl's perspective between the two regexp versions, and very little difference between the two regexp versions and the scan example. % dis script { regexp {([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})} 192.168.101.20 _ a b c d } ByteCode 0x0x24cfd30, refCt 1, epoch 15, interp 0x0x2446670 (epoch 15) Source " regexp {([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-" Cmds 1, src 90, inst 19, litObjs 8, aux 0, stkDepth 8, code/src 0.00 Commands 1: 1: pc 0-17, src 1-89 Command 1: "regexp {([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9" (0) push1 0 # "regexp" (2) push1 1 # "([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})" (4) push1 2 # "192.168.101.20" (6) push1 3 # "_" (8) push1 4 # "a" (10) push1 5 # "b" (12) push1 6 # "c" (14) push1 7 # "d" (16) invokeStk1 8 (18) done % dis script { regexp {^(\d+)\.(\d+)\.(\d+)\.(\d+)$} 192.168.101.20 _ a b c d } ByteCode 0x0x24d1730, refCt 1, epoch 15, interp 0x0x2446670 (epoch 15) Source " regexp {^(\d+)\.(\d+)\.(\d+)\.(\d+)$} 192.168.101.20 _" Cmds 1, src 64, inst 19, litObjs 8, aux 0, stkDepth 8, code/src 0.00 Commands 1: 1: pc 0-17, src 1-63 Command 1: "regexp {^(\d+)\.(\d+)\.(\d+)\.(\d+)$} 192.168.101.20 _ " (0) push1 0 # "regexp" (2) push1 1 # "^(\d+)\.(\d+)\.(\d+)\.(\d+)$" (4) push1 2 # "192.168.101.20" (6) push1 3 # "_" (8) push1 4 # "a" (10) push1 5 # "b" (12) push1 6 # "c" (14) push1 7 # "d" (16) invokeStk1 8 (18) done % dis script { scan 192.168.101.20 %d.%d.%d.%d a b c d } ByteCode 0x0x24d1930, refCt 1, epoch 15, interp 0x0x2446670 (epoch 15) Source " scan 192.168.101.20 %d.%d.%d.%d a b c d " Cmds 1, src 41, inst 17, litObjs 7, aux 0, stkDepth 7, code/src 0.00 Commands 1: 1: pc 0-15, src 1-40 Command 1: "scan 192.168.101.20 %d.%d.%d.%d a b c d " (0) push1 0 # "scan" (2) push1 1 # "192.168.101.20" (4) push1 2 # "%d.%d.%d.%d" (6) push1 3 # "a" (8) push1 4 # "b" (10) push1 5 # "c" (12) push1 6 # "d" (14) invokeStk1 7 (16) done However, if you look at the time results from these examples, they are very different. % time { regexp {([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})} 192.168.101.20 matched a b c d } 100000 11.29749 microseconds per iteration % time { regexp {^(\d+)\.(\d+)\.(\d+)\.(\d+)$} 192.168.101.20 _ a b c d } 100000 7.78696 microseconds per iteration % time { scan 192.168.101.20 %d.%d.%d.%d a b c d } 100000 1.03708 microseconds per iteration Why is that? Well, bytecode is a good indicator, but it doesn't address the inherent speed of the commands being invoked. Regex is a very slow operation comparatively. And within the regex engine, the second example is a simpler regex to evaluate, so it's faster (though less accurate, so make sure you are actually passing an IP address.) Then of course, scan shows off its optimized self in grand fashion. Was this a useful exercise in understanding Tcl under the hood? Drop some feedback in the comments if you'd like more tech tips like this that aren't directly covering a product feature or solution, but reveal some utility that assists in learning how things tick.The Double Whammy of Scripting
Many of you are very familiar with iRules, our Tool Command Language (Tcl) based scripter. It’s a powerful application delivery tool to have a programmable proxy that allows you to manipulate – in real time - any network traffic passing through the BIG-IP. Many BIG-IP fans have used it to address their specific needs and some iRules have even been productized as features. For example, the cool ASM Data Mask feature that blocks sensitive info like SSN or credit card numbers from leaking out was once an iRule. Aw, our baby made it to the BIGs. And by now you may have heard the trumpets about iRules LX, available in our most recent BIG-IP v12.1 release. So I was wondering if you were wondering what’s the difference between iRules and iRules LX? Why would you use one or the other? iRules is based on Tcl and is an extremely stable and well-documented solution. We introduced it in BIG-IP v9.0 and we continue ongoing feature development for it. iRules Language eXtensions (where the LX comes from) is the next-generation of network programmability based on JavaScript. IRules LX is not intended to replace or antiquate Tcl, but provide additional functionality in certain situations. Say you are writing a rule in Tcl that looks for some piece of data. When you find that data, you then need to make a database call to verify the parameters. That could get messy with many lines of code. You may even say to yourself, ‘Geeze, this would be a whole lot easier if I had a parser…wouldn’t that be nice.’ This is where IRules LX can be handy. Toss it over to a Node.js extension and let it do the work. With the proper node package manger (npm), of which there are some 280,000 (and counting), iRules LX will process and send back to Tcl so you can go on your merry way. Essentially, that last 10% is 90% of the work so why not have a proper engine run it. iRules LX is a simple way to solve tough challenges…another tool to use when you need it. Granted, it is not necessarily a hammer but that particular hex tool for precise jobs. It also bridges into the new world of programming. Tcl is still very relevant yet Node.js a popular, cutting edge language that the development community has eaten up. It offers more flexibility when you need it and a new tool in your arsenal of application delivery solutions. You should also check out Eric Flores' Getting Started with iRules LX series which covers some concepts, use cases, configurations and workflows. ps Related: Introducing iRules LX Getting Started with iRules LX June is Programmability Month!To Comment or Not to Comment?
Lindsay Hill wrote an article on iRules comments on his site that got me thinking about comments in general. As I prepared to just bring forth some insightful commentary on using comments in iRules, the majority of the quotes I found are actually bent against commenting in code. My favorites: Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed? - Steve McConnell Every time you write a comment, you should grimace and feel the failure of your ability of expression. - Unknown I'm more than a little knotted up over this idea of not commenting the code. For well-maintained source code in large projects, maybe this is a best practice. For scripts like iRules, however, I'm a big fan of commentary. The reality is that in operational environments, people come and go and, well, even the original author might need a refresher course on what the iRule does after a few (weeks?) months go by and an emergency hits at 3am. Clear documentation in the iRule can go a long way to providing clarity on iRule overall and event/section functionality, especially for the operations on-call looking at not only your iRule for the first time, but perhaps AN iRule for the first time. Another reason for using comments over readable code can be found in #6 of Joe's 10 steps to iRules optimization, which states that longer variable names, whereas making the code more readable, actually have memory implications. Now that I've waxed philosophically on whether or not to include comments, how do you actually do it? Well, the formal comment is accomplished with the pound sign. From the Tcl wiki: If A hash character ("#") appears at a point where Tcl is expecting the first character of the first word of a command, then the hash character and the characters that follow it, up through the next newline, are treated as a comment and ignored. The comment character only has significance when it appears at the beginning of a command. # single line comment started with the hash or pound sign. when HTTP_REQUEST { log local0. "Request event has fired" ; # in-line comment. Lead with a semi-colon. } This is the most commonly seen method of commenting. Something Tcl doesn't support natively like most other languages is the multi-line comment. However, it can be done without commenting each line out. There are many workarounds for this, two of which are shown below. Option 1 One way to comment out many lines is to use a false condition. if 0 { set x 13 set y 15 set product [expr {$x * $y}] } Note that using this method will still require all the lines to be valid iRules lines. The syntax validator will allow the previous example as all lines are valid, but will not allow the example below. if 0 { this is a comment and I can put anything here that I want to. } error: [undefined procedure: this][this is a comment and I can] error: [undefined procedure: put][put anything here that I want] error: [undefined procedure: to][to] This is a good option if you want to comment out a large existing section of code quickly to isolate issues in other sections of code. Option 2 Another way to comment many lines of code is to just to wrap them in a variable. No valid code necessary for this option, as evidenced by a fake command in HTTP::nonsense and a pool that does not exist in undefinedpool. This passed the syntax validator just fine. set comment { this is a comment on multiple lines with non-existent commands and objects yet will save just fine if ([HTTP::nonsense] eq "/test") { pool undefinedpool } } The Fine Print Whereas both these methods work, I'd recommend only using them during development and/or troubleshooting exercises. Why? Well, with the formal comment, Tcl ignores all that and it doesn't get compiled down to bytecode. That is not the case for these options. The code in the false condition will never run and the variable may never be called, but both approaches unnecessarily consume system resources. The first option consumes memory and runtime resources, the the second option only memory. Oh, one more thing. Even in these methods, you need to match your brackets or the syntax validator will complain. Note that this is true even with the formal comments as well when strung together. What other approaches to multi-line comments in Tcl/iRules have you seen or used? Drop a #comment below!
F5 Friday: You Will Appsolutely Love v11
#v11 #iApp #devops Bring dev and ops closer together to enable IT as a Service and repeatable, consistent application deployments. The overriding theme of BIG-IP v11 is its focus on applications. From security to availability to management to resiliency, this release is focused on applications. Its revolutionary approach to application services offer immediate and future operational benefits by taking another step toward a dynamic data center. iApp is a feature name for what are fundamentally programmable application templates. These templates make simple user interfaces for complex system configurations. The minimal UI requirements are defined from the existing template wizard system within BIG-IP’s GUI. Unlike the template wizard system, however, after the user fills out the form they can return and edit the form again; iApps are reentrant. The system also keeps track of all the objects associated with a given application, creating a higher level view of the configuration. Finally, the application template specification is readable and editable by end users, so they can construct their own templates, or modify existing templates to better suit their needs. IT REALLY is THAT EASY The presentation, the GUI, is described using TCL. This describes the UI and the choices offered for configuration such as IP addresses of API and associated HTTP endpoints. The result is a configuration GUI based on the template. This is displayed within the BIG-IP GUI and used to configure the application service for deployment. The configuration options specified by the administrator are stored in the iApp as variables. Templates are reentrant, meaning administrators can modify the configuration at any time, unlike wizards which generally require a linear configuration process. The variables are then available in the “implementation” section of the template. The implementation section can perform any action that can be performed via TCL – including CRUD configuration via the TMSH scripting interface What this process provides is a repeatable application deployment pattern. It reduces the potential for misconfiguration by restricting input and providing the means to verify and validate that input. Being reentrant provides the capability to adapt to changing operational and business conditions through reconfiguration. iApps are also capable of performing custom methods that can be used for a variety of interactive and non-interactive actions. For example, an interactive action might be to dynamically turn on a “sorry page” for users without persistent connections, disable all nodes, quiesce connections and then down the nodes. Another possibility is to interrogate switches via SNMP or invoking programmatic interfaces such as VMware vSphere API to determine where, topologically, a node (application instance) is located. This would be particularly useful in dynamic, virtualized environments such as cloud computing in which instances are volatile and provisioning occurs often as part of a larger, more network-inclusive provisioning process. Non-interactive custom actions are event-based and thus could be triggered on events currently supported by TMOS (which are too lengthy to list but include options across security, access and general traffic management). For example, one might run a custom action periodically to collect and/or calculate a user-defined statistic and publish the value as part of the application. Another option might be to trigger an action based on average latency of responses: when it increases above X, deploy additional instances of the application via the server infrastructure framework. Custom methods is a control plane framework similar to iRules in that they provide the means to manage infrastructure state within BIG-IP and programmatically codify specific operational processes that improve the efficiency of the provisioning and run-time environments. BRIDGING the GAP CHASM between DEV and OPS The devops movement speaks often of the need to bridge the chasm that exists between developers and operations and they have begun the process of building that bridge by adopting development methodologies that better enable consistent, repeatable application deployments in terms of their supporting infrastructure. But they have not yet truly embraced the idea of bridging that chasm by making infrastructure services more accessible to developers. That requires a fundamental change in language and perspective, such as iApp offers. Operators are still required – the operational parameters required to configure BIG-IP and infrastructure in general requires a certain baseline knowledge of networking and infrastructure most developers do not hold. But just as developers are more than capable of configuring and creating the application deployment packages required by application server platforms, so too are they capable of configuring and creating the application delivery service packages required by infrastructure to successfully deploy applications into a production network if the information is presented in a more developer friendly way. Certainly iApp is no panacea to the problem, but it is a huge leap forward toward closing the divide between developers and operations. Consider checking out the iApp resources here on DevCentral for a more thorough view into iApp and its unique capabilities: iApp Group iApp Wiki iApp Codeshare Happy deployments! F5 Monday? The Evolution To IT as a Service Continues … in the Network F5 Friday: The Gap That become a Chasm Beware the Cloud Programmer This is Why We Can’t Have Nice Things All F5 Friday Posts on DevCentral ABLE Infrastructure: The Next Generation – Introducing v11 Automating Web App Deployments with Opscode Chef and iControlSo Yeah, Regex is Bad
Don’t get me wrong, regex is awesome, and entirely useful—sometimes it’s the only option, it’s just not the best tool of choice for wire speed applications. Often the sys-admin and network type converts to BIG-IP will find the regexp tcl command and go that route because it’s familiar. If that describes you, please let me introduce you to a couple more appropriate commands: scan string These two commands will cover a great percentage of regexp’s use cases, and will save significant resources on the system. Don’t buy it? Here’s an example: % set ip "10.10.20.200" 10.10.20.200 % time { scan $ip {%d.%d.%d.%d} a b c d} 10000 2.1713 microseconds per iteration % time {regexp {([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})} $ip matched a b c d} 10000 34.2604 microseconds per iteration Two approaches, same result. The time to achieve that result? The scan command bests regexp by far. I’ll save you the calculation…that’s a 93.7% reduction in processing time. 93.7 percent! Now, mind you, the difference between 2 and 34 microseconds will be negligible to an individual request’s response time, but in the context of a single system handling hundreds of thousands or even millions of request per second, the difference matters. A lot. Thanks to (who else?) hoolio for the example. For other optimization considerations, check out the iRules Optimization 101 series. Related Articles iRules 101 - #14 - TCL String Commands Part 2 > DevCentral > F5 ... iRules 101 - #13 - TCL String Commands Part 1 > DevCentral > F5 ... iRules 101 - #16 - Parsing Strings with the TCL Scan Command ... s/regex/English/g Scan - Making string manipulation efficient > DevCentral > F5 ... Regex - DevCentral - F5 DevCentral > Community > Group Details ... REGEX Alternatives - DevCentral - F5 DevCentral > Community ... Regex in STREAM::expression - DevCentral - F5 DevCentral ... String map and redirect - DevCentral - F5 DevCentral > Community ... string manipulation - DevCentral - F5 DevCentral > Community ... Technorati Tags: F5 DevCentral,regex,regexp,scan,string,tcl,iRules,performance,Jason Rahm
