1145498 - Investigate the overhead of ServiceWorker on FxOS

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Ting-Yu Chou [:ting] (away)]

V3 architecture is going to rely on ServiceWorker heavily, there're some concerns that it may not ideal for improving application startup time. This bug is opened to understand its overhead.

Comment 1

[Ting-Yu Chou [:ting] (away)]

Food I just swallowed:

- https://blog.wanderview.com/sw-builds/
  * the builds here are debugging enabled
  * based on the statements, not so sure is current implementation of service worker good enough for this investigation, if it is not, the test result will not mean anything...

- https://wiki.mozilla.org/Gaia/Architecture_Proposal
  * this sequence seems long to me: fetch -> Render store -> Custom store -> Offline store -> Network
  * render cache stores serialized version of a particular view, so serialize/deserialize performance will be critical

- https://groups.google.com/forum/#!topic/mozilla.dev.gaia/f-vR4H5wj6Y
  * https://github.com/fxos/contacts
  * https://github.com/arcturus/serviceworkerware/

- http://www.html5rocks.com/en/tutorials/service-worker/introduction/
  I noticed possiblily overhead from the sample code:
  * clone request/response
  * IPC
  * speed of cache accessing compare to network (WiFi), especially when the cache is large

Comment 2

[Ting-Yu Chou [:ting] (away)]

The first thing I'd like to try is compare the resource loading from ServiceWorker cache and JAR.

Comment 3

[Ting-Yu Chou [:ting] (away)]

(In reply to Ting-Yu Chou [:ting] from comment #2)
> The first thing I'd like to try is compare the resource loading from
> ServiceWorker cache and JAR.

I will try with this sample: https://github.com/mdn/sw-test.

Not sure does service worker work on packaged app (it's not https), if not, I'll just open it by browser and make the sample a packaged app (without using service worker) to compare.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

I can tell you Cache has not been optimized yet.  We have known things we want to do, but need to get v1 feature complete first.

So I think its a bit early to take this task on.  That being said, I'm interested in the results.

What I'd really like right now is a standalone page that stresses Cache in a number of ways:

  1) Stress number of Cache entries
  2) Stress size of Response bodies
  3) Stress concurrent operations

And then look at time to complete, run time memory, and disk utilization.  This is what I intend to ultimately do in bug 1110458.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Note, the stress tests in comment 4 can all be done from a main thread window and don't need to muck with a ServiceWorker.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I should also mention the b2g builds I produce are the one exception to the sw-builds being DEBUG.  I seem to recall b2g DEBUG didn't work so well, so I do opt builds for b2g.

Comment 7

[Ting-Yu Chou [:ting] (away)]

(In reply to Ben Kelly [:bkelly] from comment #4)
> I can tell you Cache has not been optimized yet.  We have known things we
> want to do, but need to get v1 feature complete first.
> 
> So I think its a bit early to take this task on.

Ben, thanks for clarifying current status.

Thinker, then do you still think this need to be done in this week? Should we put this in backlog or change this to create a stress test instead for development?

Comment 8

[Thinker Li [:sinker]]

It is not so hurry now.  But, we should track it since service worker and other infrastructures will be improved continuously.  And, we still need to know how far we are now.

Comment 9

[Ting-Yu Chou [:ting] (away)]

Will come back later when it is the time for measurement.

Comment 10

[Ting-Yu Chou [:ting] (away)]

:overholt just told me it should be ready for measurement now.

Comment 11

[Ting-Yu Chou [:ting] (away)]

Unassigned myself as I am not working on this.