Closed
Bug 940747
Opened 11 years ago
Closed 9 years ago
HTTP cache v2: re-enable compression of cached content
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mayhemer, Unassigned)
References
(Blocks 1 open bug)
Details
I think we just need to adopt this code:
http://hg.mozilla.org/mozilla-central/annotate/24eb4aead1ba/netwerk/cache/nsCacheEntryDescriptor.cpp#l348
![]() |
Reporter | |
Updated•11 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
![]() |
Reporter | |
Comment 1•11 years ago
|
||
[ No longer blocks enabling cache2, expected to be fixed after cache2 is on ]
Blocks: cache2afterenable
![]() |
Reporter | |
Updated•11 years ago
|
No longer blocks: cache2enable
![]() |
Reporter | |
Updated•11 years ago
|
No longer blocks: cache2afterenable
Comment 2•11 years ago
|
||
Low priority IMO. I suspect most of the bulk of cached data (images, video, and lots of server-compressed HTML/JS/CSS/etc) is already compressed. This would only fix the cases where servers are too lazy to compress. We have a lot of other cache features on our backlog, and this is probably a small perf win. Also it turned out to take a long time to get right in cache v1 (and we never got it completely right).
![]() |
Reporter | |
Comment 3•10 years ago
|
||
It has been decided to not implement this feature. Based on the experience from the past, this is not that simple as it seems to be and bring more problems then good.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
(In reply to Honza Bambas (:mayhemer) from comment #3)
> It has been decided to not implement this feature. Based on the experience
> from the past, this is not that simple as it seems to be and bring more
> problems then good.
Why? I'm not sure but I guess the cache2's initial version comes with the recognition of the compressed data, then we can drop the compression feature for cache1 (and a pref for forced to enable for v1) and the avoid to bug 715198.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
![]() |
Reporter | |
Comment 5•10 years ago
|
||
Michal, you had a decent list of arguments why to not fix this, can you please list them here?
Flags: needinfo?(michal.novotny)
Comment 6•9 years ago
|
||
Most of the content comes already compressed these days, so there is very little benefit compared to added complexity to the code. My current cache contains 25963 files and only 141 of them are uncompressed html or js. Most filesystems use 4kB blocks so if the cache file is smaller than 4kB then compression has no effect. Entries with size 4-6kB would be probably compressed to a single 4kB block but entries between 6-8k might not. The compression will be efficient for entries larger than 8kB, but I have only 80 such entries in my cache. There are also other issues like that compression makes entries non-seekable.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Flags: needinfo?(michal.novotny)
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•