Name Based Virtual Hosting irule efficiency

@michael j has it right - data groups are probably best for dealing with matching against a large list of items or matching against a list that changes often. A few of the biggest advantages to using data groups over "if/then" or "switch" logic are readability and you should rarely have to touch the iRule itself. Adding a new hostname/pool-name pair just requires adding an entry to a data-group.

If you want to base the pool selection on the requested HTTP host header, you can try something like:

A data group with string entries of name: HTTP hostname and value: pool-name

ltm data-group internal test-dg {
    records {
        abc.com {
            data abc_pool
        }
        def.com {
            data def_pool
        }
    }
    type string
}

The associated iRule:

when HTTP_REQUEST {
 test-dg is a string data-group where the entries are name:value pairs
 name is the requested HTTP host header, value is the associated pool-name

     check the requested HTTP host header against entries in data-group test-dg
    if { [class match [string tolower [HTTP::host]] equals test-dg ] } {
         if the HTTP host header is in test-dg
         send the request to the pool associated with the test-dg entry
        pool [class match -value [string tolower [HTTP::host]] equals test-dg ]
    } else {
         drop the request if the host header is not in test-dg
        drop
}
}