Closed
Bug 913806
(cache2enable)
Opened 10 years ago
Closed 9 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)
2.20 KB,
patch
|
jduell.mcbugs
:
review+
|
Details | Diff | Splinter Review |
No description provided.
![]() |
Assignee | |
Updated•10 years ago
|
![]() |
Assignee | |
Updated•10 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•10 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•10 years ago
|
Alias: cache2enable
![]() |
Assignee | |
Comment 3•10 years ago
|
||
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
![]() |
Assignee | |
Updated•10 years ago
|
Blocks: cache2afterenable
![]() |
Assignee | |
Updated•10 years ago
|
![]() |
Assignee | |
Updated•10 years ago
|
![]() |
Assignee | |
Updated•9 years ago
|
Depends on: cache2tests
Depends on: 974720
Depends on: 973319
![]() |
Assignee | |
Comment 4•9 years ago
|
||
Just merged to apply.
Attachment #829369 -
Attachment is obsolete: true
Attachment #8423245 -
Flags: review?(jduell.mcbugs)
![]() |
Assignee | |
Updated•9 years ago
|
Attachment #8423245 -
Attachment is patch: true
![]() |
Assignee | |
Comment 5•9 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•9 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•9 years ago
|
||
Attachment #8423245 -
Attachment is obsolete: true
Attachment #8423445 -
Flags: review?(jduell.mcbugs)
Comment 8•9 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 10•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d61ae091de9c
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment 13•9 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•9 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•9 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•9 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•9 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•9 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•9 years ago
|
relnote-firefox:
--- → ?
Comment 19•9 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•9 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•9 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•9 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•9 years ago
|
Updated•9 years ago
|
![]() |
Assignee | |
Comment 24•9 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•9 years ago
|
||
Thanks. I used your blog post. More interesting than the doc ;)
Comment 26•9 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
Comment 28•7 years ago
|
||
Is there any reason why this is not enabled by default after 2 years?
![]() |
Assignee | |
Comment 29•7 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•7 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•7 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•6 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•6 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
•