As part of the Quantum Network initiative we are working on a project
called "Race Cache With Network" (rcwn) [1].

This project changes the way the network cache works. When we detect that
disk IO may be slow, we send a network request in parallel, and we use the
first response that comes back. For users with slow spinning disks and a
low latency network, the result would be faster loads.

This feature is currently preffed off - network.http.rcwn.enabled
In bug 1366224, which is about to land on m-c, we plan to enable it on
nightly for one or two days, to get some useful telemetry for our future
work.

For any crashes or unexpected behaviour, please file bugs blocking 1307504.

Thanks!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224

On 05/24/2017 03:36 PM, Valentin Gosu wrote:
> As part of the Quantum Network initiative we are working on a project
> called "Race Cache With Network" (rcwn) [1].
>
> This project changes the way the network cache works. When we detect that
> disk IO may be slow, we send a network request in parallel, and we use the
> first response that comes back. For users with slow spinning disks and a
> low latency network, the result would be faster loads.

Should we introduce a bias, in order to favor data coming from the alternate
data, knowing that the alternate data stream might be bigger but reduce the
upcoming work following the plain data?  The concern here is that the
alternate data might be slower to load, but faster to process.

Do we have a way, from the nsICacheInfoChannel, to distinguish when data
came from the network, as opposed to from the cache?  The concern is that we
want to avoid adding additional cost while try aggregate alternate data.
Alternate cost which might slow down the execution speed after the network
access.

Overall this sounds like an awesome idea, if the stream is known to have no
alternate data, or to compensate the alternate data savings. Maybe we could
provide some estimates for the alternate data savings, based on the mime type?

--
Nicolas B. Pierron

On 24 May 2017 at 19:01, Nicolas B. Pierron <nicolas....@mozilla.com>
wrote:

> On 05/24/2017 03:36 PM, Valentin Gosu wrote:
>
>> As part of the Quantum Network initiative we are working on a project
>> called "Race Cache With Network" (rcwn) [1].
>>
>> This project changes the way the network cache works. When we detect that
>> disk IO may be slow, we send a network request in parallel, and we use the
>> first response that comes back. For users with slow spinning disks and a
>> low latency network, the result would be faster loads.
>>
>
> Should we introduce a bias, in order to favor data coming from the
> alternate data, knowing that the alternate data stream might be bigger but
> reduce the upcoming work following the plain data?  The concern here is
> that the alternate data might be slower to load, but faster to process.
>

We already have logic in place to never race when we have alt-data in the
cache.

>
> Do we have a way, from the nsICacheInfoChannel, to distinguish when data
> came from the network, as opposed to from the cache?  The concern is that
> we want to avoid adding additional cost while try aggregate alternate data.
> Alternate cost which might slow down the execution speed after the network
> access.
>

We can use nsICacheInfoChannel.isFromCache() for that.
Bug 1358038 also adds nsICacheInfoChannel.isRacing() in order to show that
info in the devtools panel (otherwise developers might be confused as to
why their pages weren't properly cached)

> Overall this sounds like an awesome idea, if the stream is known to have
> no alternate data, or to compensate the alternate data savings. Maybe we
> could provide some estimates for the alternate data savings, based on the
> mime type?
>

So, at the moment, we never race for channels that have the
LOAD_ONLY_FROM_CACHE | LOAD_NO_NETWORK_IO flags set, if the channel is used
by service workers, if the cache entry has alt-data saved, or if the size
of the cache entry is above 256 Kb.
The trigger to race is if the size of the Cache IO queue is above a certain
threshold - which usually indicates slow disk IO, but varies greatly
between hardware configurations. We expect by the time we release this
feature to be able to watch the cache speed constantly so we'll know
exactly when the cache is slow and trigger racing.

Is there a particular reason this is landing directly to nightly rather
than using a pref experiment? A pref experiment is going to provide much
more reliable comparative data. In general we're pushing everyone to use
controlled experiments for nightly instead of landing experimental work
directly.

--BDS

On Wed, May 24, 2017 at 11:36 AM, Valentin Gosu <valent...@gmail.com>

wrote:

> As part of the Quantum Network initiative we are working on a project
> called "Race Cache With Network" (rcwn) [1].
>
> This project changes the way the network cache works. When we detect that
> disk IO may be slow, we send a network request in parallel, and we use the
> first response that comes back. For users with slow spinning disks and a
> low latency network, the result would be faster loads.
>

> This feature is currently preffed off - network.http.rcwn.enabled
> In bug 1366224, which is about to land on m-c, we plan to enable it on
> nightly for one or two days, to get some useful telemetry for our future
> work.
>
> For any crashes or unexpected behaviour, please file bugs blocking 1307504.
>
> Thanks!
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

What's the state of pref experiments? I thought they were not yet ready.

-Ekr


On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

a howto for a pref experiment would be awesome..

I'm worried we're going from too little process here to too much (at least
for this bug).  Opening a meta-bug + 4 sub-bugs and doing a legal review,
etc., is a lot of overhead to test some network plumbing that is not going
to be especially noticeable to users.

Also, we expect that this code will mostly benefit users with slow hardware
(disk drives especially).  We'll need to cast a very wide net to get
nightly users that match that profile.  The Shield docs say that
"participation for Shield Studies is currently around 1-2% of randomly
selected participants" (does that map to 1-2% of nightly users?), so I'm
not sure we'd get enough coverage if we used Shield.

Jason

On Thu, May 25, 2017 at 11:30 AM, <mgr...@mozilla.com> wrote:

> Hey folks. I run the Shield team. Pref flipping experiments ARE available
> on Nightly and will be available in all channels (including Release) at
> some point in Firefox 54.
>
> Since the process is still relatively new, I've been hacking on some how
> to docs: https://docs.google.com/document/d/16bpDZGCPKrOIgkkIo5mWKHPTlYXOa
> tyg_-CUi-3-e54/edit#heading=h.mzzhkdagng85
>
> Feel free to give those a spin. Feedback on the docs/process is welcome.

I think you were looking at the docs for opt-in Shield studies (experiments
deployed as add-ons), not for pref flipping experiments. Due to the nature
of some of the opt-in studies we run they require a different approval
process. Pref flipping is available for all users, it is not opt-in. The
process currently requires one bug and an email to release drivers.
Feedback on the doc/process is always welcome!

>I think you were looking at the docs for opt-in Shield studies

Ah, right you are :)

OK, I've filed a bug for the pref study:

   https://bugzilla.mozilla.org/show_bug.cgi?id=1367951

Thanks!

Jason

Very useful information! Helped me in a lot.