SPDY/HTTP2 Profile Impact on Variable Use

Hi Jeremy,

A given

-subtable

(and its containing keys) will always stick to the same TMM core. This approach is required to enable

[table keys]

to query just a single TMM core. Without this behavior, the a

[table keys]

command would need to query every single TMM core to get all the key names/counts. This would be a performance nightmare...

Unfortunately you can’t control/manipulate the hash-routing of an individual

-subtable

name. But you can observe the existing hash-routing behavior by clocking the elapsed

[clock clicks]

for a single

[table -subtable]

execution. A local TMM table query will in this case require significantly less clicks and therefor allows a very easy differentiation.

To simplify the discovery process and management you can also use a data-plane code block to discover a

-subtable

value that gets hash-routed to the local TMM instance. See the sample below how this could be implemented based on Jason initial iRule functionality.

when RULE_INIT {
    set static::local_tmm_maxclicks 15
}
when CLIENT_ACCEPTED {
    if { [catch {
        table set -subtable $static::local_tmm_subtable "[IP::client_addr]:[TCP::client_port]" [LB::server pool]
    }] } then {
        foreach char [split 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ ""] {
            set timestamp [clock clicks]
            table lookup -subtable "table_hash_$char" dummy
            if { [expr { [clock clicks] - $timestamp }] < $static::local_tmm_maxclicks } then {
                log local0.debug "The subtable \"table_hash_$char\" has taken \"[expr { [clock clicks] - $timestamp }]\" clicks. The table is hash-routed to the local TMM core." 
                set static::local_tmm_subtable "table_hash_$char"
                table set -subtable $static::local_tmm_subtable "[IP::client_addr]:[TCP::client_port]" [LB::server pool]
                break
            } else {
                log local0.debug "The subtable \"table_hash_$char\" has taken \"[expr { [clock clicks] - $timestamp }]\" clicks. The table is hash-routed to a different TMM core."
            }
        }
    }
}
when HTTP_REQUEST {
    set default_pool [table lookup -subtable $static::local_tmm_subtable [IP::client_addr]:[TCP::client_port]]
    log local0. "POOL: |$default_pool|"
}

Note: Your VS:: namespace is a pretty cool idea! I would second that feature request! ;-)*

Note: Well, OneConnect has its own pros but also serious cons. And to be honest, I very much dislike the way OneConnects reverts the current pool selection after every single request... 😞

Cheers, Kai