Sessionization can be applied in the pipeline via the TLSessioning session agent. Experience Analytics sessionization relies on user data in the REQ buffer to successfully perform its function.
- This session identifier can be specified as something other than an HTTP Cookie, such as a QUERY_STRING parameter.
- TLSessioning supports sessionization involving tables and table lookups. Note: When configuring the TLSessioning section in
CSS.cfg, place the section after the
[CookieParser]section. Otherwise, the session agent does not see the cookie as a REQ name/value pair.
How Tealeaf Sessioning Works
The strength and vulnerability of sessionizing are the hash tables associated with the session tables. SessionIDs are stored in buckets where the SessionID hash determines the bucket in which the SessionID resides. The goal of hashing keys is to distribute SessionIDs equally across the hash buckets. Therefore, it is important that the hash function work well with the specified SessionIDs so that the resulting bucket usage is relatively uniform. A hash function that does not work well can effectively turn into a sequential list.
Underlying storage provides 65,536 buckets for storing SessionIDs. For a site that creates a new session every second, 86,400 SessionIDs would be stored per day. With a well-distributing hash, on average there would be one or two SessionIDs per bucket. To find any random SessionID, a user extracts the hash from the SessionID, looks in the associated bucket, and performs no more than two lookups before finding the SessionID. If the hash value is not equally distributed, search times become longer, and in the capture pipeline, speed is of the essence.
Typically, sessionization requires storing 10,000 or more SessionIDs into tables. The rate at which these storage and search operations occur directly impacts the rate of sessionization.
Serially searching through the SessionID pool is very slow. Using hash keys, the database hash determines in which bucket a particular SessionID resides. For example, the standard TLTSID is a 32-byte hex-ASCII value. Bytes 5 through 8 of this string is a fairly random number, making it a good hash key for GUIDs because SessionIDs are equally distributed into buckets specified by this substring. The RTA SessPCT operator uses these 4 bytes to perform its function.
No hash performs equally well on all possible data sets. The default hash function may perform poorly with a particular set of keys. The TLSessioning configuration variable allows for specifying varying hash keys.