Remove requirement for canister safety limits for session sizes
Having the sessions get chopped up into multiple pieces skews reporting and search results. It also confuses people when they're searching for a session and get back results they're not expecting.
The way canisters handle data needs to be redesigned to make it so that the only required session cut is inactivity timeout.
I'm not saying the option to cut sessions should be removed, just the requirement to limit sessions by number of hits, total bytes, duration etc.
This is especially troublesome when using the virtual hit session agent for DOM capture which can inject dozens and hundreds of hits into a session.
-
Wesley Thompson
- Feb 28 2020
- Under consideration
| What is your industry? | Insurance |
| What is the idea priority? | Medium |
-
- +1
Related ideas
There are some architectural changes that might make this situation better. The essential problem is that active sessions are held in memory, which allows for fast and index-free searching, but to date memory cost are far higher than non-volatile storage... no reasonable amount of RAM can accommodate long duration sessions under high volume. As solid state storage costs decline (and offer very good performance) the need to store session data in main memory will also decline.
It's also worth noting that the 'active' and 'completed' session concept is confusing for Tealeaf users. As session durations are often limited by the technology and not the application design, the concept is not helpful... for example an application user may stay relatively active for 8 hours, but have that time divided arbitrarily into 'Tealeaf' sessions. It would be better to have a single "Session Search" and have the search service decide how to construct the query.
A proposal: Allow portions of an active session to be flushed to the long term canister without being logically closed. This would mean that session data would be appended to rather than being fixed. Only upon a real idle timeout or an event driven close would the session be flagged as "closed".
The search implication is that hits for a session would be found in both the short and long term canisters for sessions that are not logically closed... similar to an "All Sessions" search. This is also similar to replay session merging... where fragments are transparently combined. To accommodate indexing lag, hits in the STC would not be deleted until their LTC component is indexed. Yes, that can be a problem... the indexer becomes even more critical.
The event implication is that hit evaluation must be able to look back beyond the STC into the LTC, for example to check on whether an event exists in the session. Index performance would be critical to prevent an evaluation backlog... so perhaps critical portions of the index would be mirrored in memory.
Lastly, would bringing the SaaS architecture on-prem solve this problem better, and possibly be less work?
Attachments Open full size