File: sessions.rst

package info (click to toggle)
firefox 142.0.1-1
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 4,591,884 kB
  • sloc: cpp: 7,451,570; javascript: 6,392,463; ansic: 3,712,584; python: 1,388,569; xml: 629,223; asm: 426,919; java: 184,857; sh: 63,439; makefile: 19,150; objc: 13,059; perl: 12,983; yacc: 4,583; cs: 3,846; pascal: 3,352; lex: 1,720; ruby: 1,003; exp: 762; php: 436; lisp: 258; awk: 247; sql: 66; sed: 53; csh: 10
file content (37 lines) | stat: -rw-r--r-- 2,077 bytes parent folder | download | duplicates (27)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
========
Sessions
========

A *session* is the time from when Firefox starts until it shuts down.
A session can be very long-running. E.g. for users that always put their computers into sleep-mode, Firefox may run for weeks.
We slice the sessions into smaller logical units called *subsessions*.

Subsessions
===========

The first subsession starts when the browser starts. After that, we split the subsession for different reasons:

* ``daily``, when crossing local midnight. This keeps latency acceptable by triggering a ping at least daily for most active users.
* ``environment-change``, when a change to the *environment* happens. This happens for important changes to the Firefox settings and when add-ons activate or deactivate.

On a subsession split, a :doc:`main ping <../data/main-ping>` with that reason will be submitted. We store the reason in the pings payload, to see what triggered it.

A session always ends with a subsession with one of two reason:

* ``shutdown``, when the browser was cleanly shut down. To avoid delaying shutdown, we only save this ping to disk and send it at the next opportunity (typically the next browsing session).
* ``aborted-session``, when the browser crashed. While Firefox is active, we write the current ``main`` ping data to disk every 5 minutes. If the browser crashes, we find this data on disk on the next start and send it with this reason.

.. image:: subsession_triggers.png

Subsession data
===============

A subsessions data consists of:

* general information: the date the subsession started, how long it lasted, etc.
* specific measurements: histogram & scalar data, etc.

This has some advantages:

* Latency - Sending a ping with all the data of a subsession immediately after it ends means we get the data from installs faster. For ``main`` pings, we aim to send a ping at least daily by starting a new subsession at local midnight.
* Correlation - By starting new subsessions when fundamental settings change (i.e. changes to the *environment*), we can better correlate a subsession's data to those settings.