There is a fundamental conflict between recording data for short-lived browser sessions and performance of those browser sessions. In short, the overhead of recording the session is relatively significant in short-lived sessions compared with that same overhead occurring in a longer session. The Performance Team would like us to consider not counting short lived sessions or sacrificing the details that we capture. Metrics: in light of this constraint, what are the requirements for capturing session data? Do we need things like active/total times for "short lived" sessions? Would a count of short-lived (under N minute) sessions complemented by the active/total times of longer sessions suffice? What would be the largest value of N that would be acceptable? 1 minute? 2 minutes? 5 minutes?

I can't make the decision here, but I am happy to drive the discussion with various people. In the original prototype, we wrote the a simple journaling text file rather than the more heavy-weight DB access, so I don't believe this was as much of an issue. I think we can definitely consider deferring the collection of certain types of metrics until the session has reached a suitable age. It would be a lot better if it was a deferral rather than just throwing it away.

Daniel, who are the right people to include in this discussion? Are they all cc'd on this bug?

Metrics discussed this and we would like to collect minimal metrics for short-lived sessions. Ideally, the number and duration of completed and aborted sessions less than 2 minutes. This could be stored in a fast storage system such as the pref db or a flat file and then parsed out and integrated into the FHR payload on some subsequent session that is long enough to warrant full initialization. We have a proposed lifecycle that we will share with :gps in addition to the stuff he put in bug 827157 comment 2

(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #3) > We have a proposed lifecycle that we will share with :gps in addition to the > stuff he put in bug 827157 comment 2 Here's the english + pseudocode workflow Daniel and I discussed. Sorry about the wrapping - if it's unreadable I can add it as an attachment instead. ---- As a proposed implementation, the workflow would be something like the following. Where I reference the "fast storage" system, it could be something as simple as using the preferences DB, or it could be a plain text file in the profile directory. The "shortSessions" value could have a compact string representation like: "20130118:+15+15-3-1+100;20130119:+99" Where "+x" represents a clean session of x seconds, and "-y" represents an aborted session not longer than y, with each day's data is separated by semicolon. Workflow description: on start-up load previously recorded start-up time from fast storage -> lastStartTime = load(startTime) capture current start time -> currentStartTime = new Date() set timeout for 2 minutes check for last start-up time if exists capture currentStartTime - lastStartTime as max possible duration of an aborted session -> abortedSessionCeiling append abortedSessionCeiling to fast storage property for short-lived sessions -> append(shortSessions, '-' + abortedSessionCeiling) retrieve previous short-sessions date from fast storage -> load(lastStartDay) if current start date is greater than previous date or previous date doesn't exist append date to fast storage property for short-lived session metrics -> append(shortSessions, ';' + truncDate(currentSessionTime)) write current start time to fast storage property for last start-up time -> save(startTime, currentStartTime) write current start date to fast storage property for previous short-sessions date -> save(lastStartDay, truncDate(currentSessionTime)) on 2 minute timeout set idle timeout on idle timeout initialize Metric storage and collection systems -> this hands over full control to the "normal" data persistence layer. record metrics for previous short-sessions from the fast storage property -> serialize(shortSessions) bootstrap metrics for current session with the start time from the fast storage property -> pass currentSessionTime to current session provider erase all short-session properties from fast storage -> unset(shortSessions, startTime, lastStartDay) on clean shutdown check fast storage property for last start-up time -> load(startTime) != null if exists capture curr - prev start time as duration of a completed session -> new Date() - currentStartTime -> currentSessionDuration append completed session duration to fast storage property for short-lived sessions -> append(shortSessions, '+' + currentSessionDuration) erase current start time value in the fast storage property -> unset(startTime) This life-cycle would allow us to determine how frequent short sessions are, how long their typical duration is, and how often they are aborted, providing that the profile eventually has a session that is long enough to submit FHR data.

The latest patch in bug 827157 records all session information without data loss (even active time for short sessions). It does it in a way that doesn't hurt performance. We no longer need to make a tradeoff between complete data and performance loss. I hope.