Looking at all the metrics pings that came in the last 24 hours, 78% of them measured a start/end delta of 0 (meaning less than the 1 minute resolution of those time stamps). 24% of all pings had a zero delta and an end time at 4AM. Those values are very high for metrics pings, which should not ever be sent more than once a day. There is only one scenario in which a delta of 0 would be considered "normal". On the very first startup of the app by a user, the app will see that no ping has been sent today (or ever) and will schedule it immediately. Since the ping will start and end quite quickly, this is expected. We can detect these by filtering for pings with a `seq` of 0. This makes up 8% of the pings in the test data set (and are not included in the problematic percentages above). I believe these anomalies can be traced to the fact that ping start times are not persisted to disk and exist only in an in-memory map and on mobile platforms, the application is frequently killed by the OS. ### Scenario 1 **SYMPTOM:** A delta of 0, not ending at 4AM. The user hasn't run the app at all today, and the app is not running. The user starts the app at some time of day other than 4AM. The metrics ping scheduler sees that no ping was sent today, so schedules it for immediately. The ping collector sees that no start time is recorded for the ping, so sets it to app startup time, which is approximately "now". The end time gets set to "now". ### Scenario 2 **SYMPTOM:** A delta of 0, ending at 4AM. The user starts the app. The metrics ping scheduler sees that a ping has already been sent today, so it schedules the work manager to wake up the app at 4am tomorrow. Before the end of the day, the user closes the app, and the OS eventually kills the app. Work Manager wakes the app up at 4am to send a ping. The ping collector sees that no start time is recorded for the ping, so it sets it to app startup time which is approximately "now" at 4am. The end time also gets set to 4am.
Bug 1566488 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Looking at all the metrics pings that came in the last 24 hours, 78% of them measured a start/end delta of 0 (meaning less than the 1 minute resolution of those time stamps). 24% of all pings had a zero delta and an end time at 4AM. Those values are very high for metrics pings, which should not ever be sent more than once a day. There is only one scenario in which a delta of 0 would be considered "normal". On the very first startup of the app by a user, the app will see that no ping has been sent today (or ever) and will schedule it immediately. Since the ping will start and end quite quickly, this is expected. We can detect these by filtering for pings with a `seq` of 0. This makes up 8% of the pings in the test data set (and are not included in the problematic percentages above). I believe these anomalies can be traced to the fact that ping start times are not persisted to disk and exist only in an in-memory map and on mobile platforms, the application is frequently killed by the OS. ### Scenario 1 **SYMPTOM:** A delta of 0, not ending at 4AM. The user hasn't run the app at all today, and the app is not running. The user starts the app at some time of day other than 4AM. The metrics ping scheduler sees that no ping was sent today, so schedules it to go out immediately. The ping collector sees that no start time is recorded for the ping, so sets it to app startup time, which is approximately "now". The end time gets set to "now". ### Scenario 2 **SYMPTOM:** A delta of 0, ending at 4AM. The user starts the app. The metrics ping scheduler sees that a ping has already been sent today, so it schedules the work manager to wake up the app at 4am tomorrow. Before the end of the day, the user closes the app, and the OS eventually kills the app. Work Manager wakes the app up at 4am to send a ping. The ping collector sees that no start time is recorded for the ping, so it sets it to app startup time which is approximately "now" at 4am. The end time also gets set to 4am.
Looking at all the metrics pings that came in the last 24 hours, 78% of them measured a start/end delta of 0 (meaning less than the 1 minute resolution of those time stamps). 24% of all pings had a zero delta and an end time at 4AM. Those values are very high for metrics pings, which should not ever be sent more than once a day. There is only one scenario in which a delta of 0 would be considered "normal". On the very first startup of the app by a user, the app will see that no ping has been sent today (or ever) and will schedule it immediately. Since the ping will start and end quite quickly, this is expected. We can detect these by filtering for pings with a `seq` of 0. This makes up 8% of the pings in the test data set (and are not included in the problematic percentages above). I believe these anomalies can be traced to the fact that ping start times are not persisted to disk and exist only in an in-memory map and, on mobile platforms, the application is frequently killed by the OS. ### Scenario 1 **SYMPTOM:** A delta of 0, not ending at 4AM. The user hasn't run the app at all today, and the app is not running. The user starts the app at some time of day other than 4AM. The metrics ping scheduler sees that no ping was sent today, so schedules it to go out immediately. The ping collector sees that no start time is recorded for the ping, so sets it to app startup time, which is approximately "now". The end time gets set to "now". ### Scenario 2 **SYMPTOM:** A delta of 0, ending at 4AM. The user starts the app. The metrics ping scheduler sees that a ping has already been sent today, so it schedules the work manager to wake up the app at 4am tomorrow. Before the end of the day, the user closes the app, and the OS eventually kills the app. Work Manager wakes the app up at 4am to send a ping. The ping collector sees that no start time is recorded for the ping, so it sets it to app startup time which is approximately "now" at 4am. The end time also gets set to 4am.