Closed
Bug 913806
(cache2enable)
Opened 11 years ago
Closed 11 years ago
Turn HTTP cache v2 on by default on all products
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
RESOLVED
FIXED
mozilla32
Tracking | Status | |
---|---|---|
relnote-firefox | --- | 32+ |
People
(Reporter: mayhemer, Assigned: mayhemer)
References
(Depends on 1 open bug, Blocks 4 open bugs)
Details
(Keywords: feature, Whiteboard: [cache2])
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
jduell.mcbugs
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Blocks: http_cache
could you let cachev2 use the path specified on browser.cache.disk.parent_directory ? it would help to avoid backupping useless data during my daily disk backup
Assignee | ||
Comment 2•11 years ago
|
||
(In reply to fxtech from comment #1)
> could you let cachev2 use the path specified on
> browser.cache.disk.parent_directory ? it would help to avoid backupping
> useless data during my daily disk backup
File bug 922081 on it.
Assignee | ||
Updated•11 years ago
|
Alias: cache2enable
Assignee | ||
Comment 3•11 years ago
|
||
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Assignee | ||
Updated•11 years ago
|
Blocks: cache2afterenable
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Depends on: cache2tests
Assignee | ||
Updated•11 years ago
|
Depends on: 973319
Assignee | ||
Comment 4•11 years ago
|
||
Just merged to apply.
Attachment #829369 -
Attachment is obsolete: true
Attachment #8423245 -
Flags: review?(jduell.mcbugs)
Assignee | ||
Updated•11 years ago
|
Attachment #8423245 -
Attachment is patch: true
Assignee | ||
Comment 5•11 years ago
|
||
And here is the current Gum push: https://tbpl.mozilla.org/?tree=Gum&rev=46221d0b440e
(please ignore the Linux x64 ASAN JP timeouts, those are known and not run on m-c/m-i)
Comment 6•11 years ago
|
||
Comment on attachment 8423245 [details] [diff] [review]
enable the cache
Review of attachment 8423245 [details] [diff] [review]:
-----------------------------------------------------------------
Assuming gum results look good...
Attachment #8423245 -
Flags: review?(jduell.mcbugs) → review+
Assignee | ||
Comment 7•11 years ago
|
||
Attachment #8423245 -
Attachment is obsolete: true
Attachment #8423445 -
Flags: review?(jduell.mcbugs)
Comment 8•11 years ago
|
||
Comment on attachment 8423445 [details] [diff] [review]
enable the new cache using the _temp pref
Review of attachment 8423445 [details] [diff] [review]:
-----------------------------------------------------------------
FYI: the reason we're using the _temp pref is so that in case we need to back out, people who opted-in to new_cache=1 won't have that pref unset. If we stick we'll get rid of the _temp pref and make new_cache=1 the default.
Attachment #8423445 -
Flags: review?(jduell.mcbugs) → review+
Comment 9•11 years ago
|
||
Comment 10•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment 13•11 years ago
|
||
When the new cache was turned on we saw a ~15MB bump in RSS memory usage and ~11MB bump in Explicit memory usage:
https://areweslimyet.com/mobile/
It looks like the Explicit jump is due to network/cache2/disk-storage() which wasn't reported before turning on, but is now ~10MB. Is this memory that just wasn't reported before with the old cache?
I don't know the specific cause of the ~15MB RSS jump.
Assignee | ||
Comment 14•11 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #13)
> When the new cache was turned on we saw a ~15MB bump in RSS memory usage and
> ~11MB bump in Explicit memory usage:
Filed bug 1013333 on this.
Comment 15•11 years ago
|
||
Looking at the patch, it's not clear to me how to use prefs to switch the new cache off.
It adds a new pref:
browser.cache.use_new_backend_temp = true
It keeps the old pref with the same value:
browser.cache.use_new_backend = 0
How do I switch it off now for the sake of some testing?
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 16•11 years ago
|
||
(In reply to Avi Halachmi (:avih) from comment #15)
browser.cache.use_new_backend_temp = false and keep browser.cache.use_new_backend = 0
Flags: needinfo?(honzab.moz)
Comment 17•11 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #16)
> (In reply to Avi Halachmi (:avih) from comment #15)
>
> browser.cache.use_new_backend_temp = false and keep
> browser.cache.use_new_backend = 0
Thanks.
I'm guessing that at some stage in the future browser.cache.use_new_backend_temp will go away and be ignored, and browser.cache.use_new_backend = 0 or 1 will control if it's the new or old cache?
Assignee | ||
Comment 18•11 years ago
|
||
(In reply to Avi Halachmi (:avih) from comment #17)
> (In reply to Honza Bambas (:mayhemer) from comment #16)
> > (In reply to Avi Halachmi (:avih) from comment #15)
> >
> > browser.cache.use_new_backend_temp = false and keep
> > browser.cache.use_new_backend = 0
>
> Thanks.
>
> I'm guessing that at some stage in the future
> browser.cache.use_new_backend_temp will go away and be ignored, and
> browser.cache.use_new_backend = 0 or 1 will control if it's the new or old
> cache?
My idea is to remove _temp before merge to aurora. _new should go away with the old cache code which is not gonna happen this release.
Updated•11 years ago
|
Updated•10 years ago
|
relnote-firefox:
--- → ?
Comment 19•10 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #18)
> My idea is to remove _temp before merge to aurora. _new should go away with
> the old cache code which is not gonna happen this release.
(Where) Did this happen?
Flags: needinfo?(honzab.moz)
Comment 21•10 years ago
|
||
Honza, I am working on the release notes for 32 and 33 and this bug has been marked. Do you confirm that this feature is enabled by default in 32? Thanks
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 22•10 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #21)
> Honza, I am working on the release notes for 32 and 33 and this bug has been
> marked. Do you confirm that this feature is enabled by default in 32? Thanks
Yes, it sticks in 32!
Flags: needinfo?(honzab.moz)
Comment 23•10 years ago
|
||
Thanks Honza.
I added "New HTTP caching (v2) enabled by default" to the release notes.
I have a few more questions for you:
* Do you have some documentations on this? Blog post, MDN? I would like to add a link for advanced users.
* Does it impact also Firefox Android?
* Are you happy about the wording?
Thanks
Flags: needinfo?(honzab.moz)
Updated•10 years ago
|
Updated•10 years ago
|
Assignee | ||
Comment 24•10 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #23)
> Thanks Honza.
> I added "New HTTP caching (v2) enabled by default" to the release notes.
>
> I have a few more questions for you:
> * Do you have some documentations on this? Blog post, MDN? I would like to
> add a link for advanced users.
You can use:
http://www.janbambas.cz/new-firefox-http-cache-enabled/
https://developer.mozilla.org/en-US/docs/HTTP_Cache
> * Does it impact also Firefox Android?
It does and it should be a positive impact :)
> * Are you happy about the wording?
Yep, thanks.
>
> Thanks
Flags: needinfo?(honzab.moz)
Comment 25•10 years ago
|
||
Thanks. I used your blog post. More interesting than the doc ;)
Comment 26•10 years ago
|
||
Note we're not actually running our tests with the new cache enabled - and there are currently leaks if it is switched on for them:
https://tbpl.mozilla.org/?tree=Try&rev=a1ea7549c4fd
Bug 1053517 is an absolutely blocker for leaving this on release IMO.
Depends on: 1053517
Updated•10 years ago
|
Comment 28•9 years ago
|
||
Is there any reason why this is not enabled by default after 2 years?
Assignee | ||
Comment 29•9 years ago
|
||
(In reply to kamil from comment #28)
> Is there any reason why this is not enabled by default after 2 years?
It is.
Comment 30•9 years ago
|
||
this may sound stupid, am I having the benefit of new cache having prefs as followed:
user_pref("browser.cache.use_new_backend", 0);
user_pref("browser.cache.use_new_backend_temp", true);
or I have to flip browser.cache.use_new_backend = 1 as well?
Assignee | ||
Comment 31•9 years ago
|
||
(In reply to marvinhk from comment #30)
> this may sound stupid, am I having the benefit of new cache having prefs as
> followed:
> user_pref("browser.cache.use_new_backend", 0);
> user_pref("browser.cache.use_new_backend_temp", true);
>
> or I have to flip browser.cache.use_new_backend = 1 as well?
You have it right. the _temp pref is a leftover from times we were testing. The prefs will be gone when we remove the old cache code altogether.
Comment 32•8 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #31)
> (In reply to marvinhk from comment #30)
> > this may sound stupid, am I having the benefit of new cache having prefs as
> > followed:
> > user_pref("browser.cache.use_new_backend", 0);
> > user_pref("browser.cache.use_new_backend_temp", true);
> >
> > or I have to flip browser.cache.use_new_backend = 1 as well?
>
> You have it right. the _temp pref is a leftover from times we were testing.
> The prefs will be gone when we remove the old cache code altogether.
For clarification, the browser.cache.use_new_backend pref doesn't do anything anymore since we've been on the new one for several years, correct?
Assignee | ||
Comment 33•8 years ago
|
||
(In reply to jwms from comment #32)
> For clarification, the browser.cache.use_new_backend pref doesn't do
> anything anymore since we've been on the new one for several years, correct?
Yes, use_new_backend_temp one has wight over use_new_backend.
You need to log in
before you can comment on or make changes to this bug.
Description
•