Closed Bug 1325331 Opened 3 years ago Closed 3 years ago

Continuously watch cache speed and detect delays in the request processing

Categories

(Core :: Networking: Cache, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox53 --- affected

People

(Reporter: michal, Assigned: michal)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-active])

We should detect that the requests start to lag and the cache IO queue starts to grow. Once that happens we should prefer network requests over cache requests until the IO queue returns to normal.
Depends on: 1325336
Blocks: 1325341
Will this also adjust to account for slow network at the same time?  It seems you need both pieces of information at the same time to really make the right decision here.
Assignee: nobody → michal.novotny
Whiteboard: [necko-active]
No longer blocks: 1354407
(In reply to Michal Novotny (:michal) from comment #0)
> We should detect that the requests start to lag and the cache IO queue
> starts to grow. Once that happens we should prefer network requests over
> cache requests until the IO queue returns to normal.

From Bug 1325336

> We should have some performance data on how fast the cache is when the disk
> is not stressed by excessive IO. We can continuously collect average time of
> open, read, write operations when the cache IO queue is short. Then we can
> use this data when deciding whether to fetch the resource from the network
> or from the cache. Also bug 1325331 can compare current data with this
> statistics to detect delays.

Sorry if i misunderstood it,
but would this not have a negative effect on the users?

what is meant is 
most people will have slow hardware compared to fast connection,
even if a task is running in the background using Disk i/o Firefox might read it wrongly! Too many variables.
but when it comes to **cost saving vs a bit of delay the former wins** , as
in real usage scenarios the user has to worry about data caps and by not using cache it's will result in more data usage.

Most users want to use more cache and less bandwidth eg see

Bug 1367517

It raises a fairly good point and it should be considered as it the right way

(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #1)
> Will this also adjust to account for slow network at the same time?  It
> seems you need both pieces of information at the same time to really make
> the right decision here.

what about loading multiple bookmarks?
on a slow/fast connection?
What will be the data use overhead impact on users with data caps?
Most sites keep cache for long periods as it is cost effect for both parties,
even fb/twitter have started doing it more to save costs.

You guys know better but please keep the general users in mind who would always prefer loading things from cache even if
it results in a tad slower performance than to increase data usage for tiny improvement.
A pref to disable it would be nice.

Please do help me out understanding this :)
Flags: needinfo?(michal.novotny)
Flags: needinfo?(bkelly)
Flags: needinfo?(bkelly)
(In reply to shellye from comment #2)
> A pref to disable it would be nice.

It will be possible to disable this feature.
Flags: needinfo?(michal.novotny)
This was fixed in bug 1325336.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
how can this be disabled?

any stats available to show the gains on slow networks?
Flags: needinfo?(michal.novotny)
(In reply to shellye from comment #5)
> how can this be disabled?

You can't disable watching the cache speed. If you mean RCWN feature, you can control it with network.http.rcwn.enabled.
 
> any stats available to show the gains on slow networks?

It's not expected that RCWN brings any gain on slow networks. See bugs 1354409, 1354407 and 1354405 for telemetry related to RCWN.
Flags: needinfo?(michal.novotny)
(In reply to Michal Novotny (:michal) from comment #6)
> (In reply to shellye from comment #5)
> > how can this be disabled?
> 
> You can't disable watching the cache speed. If you mean RCWN feature, you
> can control it with network.http.rcwn.enabled.
>  
> > any stats available to show the gains on slow networks?
> 
> It's not expected that RCWN brings any gain on slow networks. See bugs
> 1354409, 1354407 and 1354405 for telemetry related to RCWN.

thanks
You need to log in before you can comment on or make changes to this bug.