863988 - Long latency during email startup

Status: RESOLVED DUPLICATE of bug 892069

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P1)

Description

[[e-mail]]

in continuation to the discussion we had on bug 817095, creating this new bug as we are seeing more regression in Email launch latency.

We use fairly loaded (around 200 mails)  gmail account to test the launch latencies in concurrency sequency (Applications like Music, SMS, Contacts, Browser and then Email).
We use high speed camera to measure the first launches and subsequent launches. 

The two major issues we see with the Email app are
1) Regression in email latency
   We have observed that the launch latency has been increased from past 2 weeks. 
We got the best launch latency of 3 secs ( from icon highlight to complete rendering of email list on the first page) on April 2nd. Later on the values have been raised and the latest value we observed is 3.8 secs results in about .8 secs increase. 

2) Lot of variations in load times of EMail application. 
   We certainly agree that the loading and rendering of email list depends on certain factors like network bandwidth and system load. However, we see the numbers are really off by upto more than 1 sec across runs. Even the datazilla numbers says the same (Difference between max and min is greater than a sec).
We need to speed up loading unless it is only caused by network. We generally test with WiFi and the domain is always google.com.

Comment 1

[[e-mail]]

We verified these on 1.1 branch.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Reporter: Can you please provide the expected perf target in seconds for these two points (email latency, launch times) - the second point does seem to leave a lot of room for network issues being the primary problem with the data variance.

Andrew - can you look into the date range in comment 0, point 1 and see if anything stands out that would have affected latency?

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

We landed (uplifted) worker thread support in bug 814257 on v1-train on April 8th.  This was expected to regress start-up for the cases where we already have an account, but the trade-off for user responsiveness was judged worth it by Andreas, Vivien, etc.

We also landed various mitigating enhancements to defer loading, but they would have improved tihngs.

Network issues do not particularly enter into the time it takes us to load the messages from an already existing/synchronized inbox, although they can impact how much time we waste with our spinner animations dominating the CPU and slowing down our startup.

Any variance in datazilla for the time-to-load metric is largely out of our hands.  We do almost nothing in that code path, so any delays are likely other processes interfering with our startup or the test infrastructure starting us without a pre-spun-up plugin thread, etc.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Minusing for blocking given Andrew's comments it looks like we're at our best results for v1.1, unless we are given a metric to try and (reasonably) meet then we can re-open the discussion.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Bug 864414 just landed on gaia/master and we are targeting an uplift to v1-train.  Since it drops our startup time (using manual metrics run by jrburke) from ~3000ms to ~1800ms, it's a major win, and we'd be particularly interested in seeing what the high speed methodology says about it.  I'll drop a note here once we uplift to v1-train, but if the camera can be run on a gaia/master checkout already (and it's okay to do on a b2g18 v1-train build), the results should be about the same.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

The v1-train uplift has happened, so if QC can do a high frequency camera run on v1-train that would be excellent.  Please make sure to start the e-mail app at least once after creating your new account to make sure that the cache has had a chance to populate fully, etc.

Comment 7

[[e-mail]]

Glad to hear about these new Wins. I will post the highspeed camera readings from our side by Friday.

Comment 8

[[e-mail]]

Average Latency	With and without patch from #864414
Email 	3.75 secs	2.54 Sec

There is a 1.2 secs improvement. Good job and thanks.

Comment 9

[[e-mail]]

This is measured with high speed camera and our concurrency launch of multiple apps.
Without patch it was 3.75Sec and with patch it is taking 2.54 secs.
 
(In reply to [e-mail] from comment #8)
> Average Latency	With and without patch from #864414
> Email 	3.75 secs	2.54 Sec
> 
> There is a 1.2 secs improvement. Good job and thanks.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

Is this still an issue since the large email refactor that happened?

Comment 11

[James Burke [:jrburke]]

It should not be an issue any more, particularly after bug 892069 has landed, which will be included in 1.2. As far as I know, this should be considered fixed unless there are new measurements that show a particular problem. See also:

https://datazilla.mozilla.org/b2g#closedataset

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

Thanks James!  Marking as a dupe of 892069.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

It's worth noting that while we now show last time's content amazingly early, it still takes some time for the back-end to catch-up with the front end, so the UI is not 100% functional for the first few seconds.  (However, a lot of the key things do work thanks to jrburke; like you can tap on a message in the list to start the process of displaying it, etc.)

Now that we have integration tests happening for the e-mail app, we will want to quantify that delay (in another bug).