SPDY/HTTP2 Profile Impact on Variable Use
When using SPDY/HTTP2 profile, TCL variables set before the HTTP_REQUEST event are not carried over to further events. This is by design as the current iRule/TCL implementation is not capable of hand...
Published Dec 19, 2016
Version 1.0JRahm
Admin
Joined January 20, 2005
JRahm
Admin
Joined January 20, 2005
Kai_Wilke
Mar 27, 2017MVP
Hi Jeremy,
both, the handcrafted
$static::cmp_hash_array()
as well as the auto discovered $static::local_tmm_subtable
examples should work well.
The values of the
$static::cmp_hash_array([TMM::cmp_unit])
needs to be discovered manually by doing some timing test. Once the values for each TMM core are figured out, the array can be created once and remain unchanged until the numbers of TMM cores is getting changed (aka. RMA unit, changed vCMP provisioning, etc.).
The overhead of the
if { [catch { Try access to $static::local_tmm_subtable }] } then { Discover $static::local_tmm_subtable }
is very small and performs even slightly better then using a [info exists static::local_tmm_subtable]
syntax. Also keep in mind that the rather complex discovery code path, need to run only a single time on each TMM core. Subsequent request on the same TMM, will be able to reuse $static::local_tmm_subtable
just fine and won't cause any [catch]
exemptions anymore.
In the end the handcrafted approach will run just marginal faster than the auto-discover example.
Your "TMM::hash" ideas.
Right now I don't see any valuable usecases for such commands.
Your "table" ideas.
It would be indeed a cool thing to have a
[table -local_tmm]
command switch to bypass hash-routings to simply stick to the local TMM core. This would allow data storage on a per-TMM level. It would be slightly slower than using $static::namespace variables, but with added functionality of a build-in garbage collection (via -timeout
/ -lifetime
switches).
Your "New Variable Scope" ideas
I've checked the outcome of
[info level]
. The underlying TCP connection and the individual HTTP/2 request are both running in level = 2. This means that TCL can't uplevel/upvar from the HTTP/2 request/response into the TCP connection. I guess a introduction of a new TCL variable scope which spanns the individual HTTP/2 connections and the underlying TCP connection should be very difficult to implement and I even wonder if this would even be possible without rewriting TCL way too much... 😞
Cheers, Kai