Necko/Cache/Plans: Difference between revisions
Jump to navigation
Jump to search
(→People) |
|||
| Line 24: | Line 24: | ||
== Design Requirements == | == Design Requirements == | ||
* Version API for the cache so we can update easily. | |||
* All APIs should be async. No main-thread locking or i/o at all. | * All APIs should be async. No main-thread locking or i/o at all. | ||
* A crash should not invalidate the entire cache. | * A crash should not invalidate the entire cache. | ||
* Support | * Support gzip compression. Meta-data should say whether a file is gzip'd or not, can choose to write compressed or uncompressed data on a per-file basis at runtime. Pass through files gzip'd from the network. | ||
* Make use of fallocate. | * Make use of fallocate. | ||
* Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API. | * Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API. | ||
| Line 33: | Line 33: | ||
* Competing ideas: | * Competing ideas: | ||
** Temporal layout so that sub-resources are together. | ** Temporal layout so that sub-resources are together. | ||
** Don't over-optimize on-disk storage, use one file per entry | ** Don't over-optimize on-disk storage, use one file per entry and let OS optimize. | ||
== Performance Goals == | == Performance Goals == | ||
Revision as of 17:30, 11 March 2013
New Cache Plans
People
We have decided to rewrite the HTTP disk cache.
The design team will be responsible for coming up with a design for the new disk cache. The design should be thorough and well-documented. Once the design team is satisfied with an initial design document, the implementation team will start implementing.
Design team:
- Michal Novotny
- Taras Glek
- Steve Workman?
- Honza Bambas
- Nick Hurley
- Brian Bondy
- Doug Turner
- Patrick McManus
- Josh Aas
Implementation team:
- Honza Bambas?
- Steve Workman?
Design Requirements
- Version API for the cache so we can update easily.
- All APIs should be async. No main-thread locking or i/o at all.
- A crash should not invalidate the entire cache.
- Support gzip compression. Meta-data should say whether a file is gzip'd or not, can choose to write compressed or uncompressed data on a per-file basis at runtime. Pass through files gzip'd from the network.
- Make use of fallocate.
- Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API.
- Effectively eliminate memory cache.
- Competing ideas:
- Temporal layout so that sub-resources are together.
- Don't over-optimize on-disk storage, use one file per entry and let OS optimize.
Performance Goals
- Primary performance target is mobile - Android and Firefox OS. On-disk layout must optimize for this.
- Make sure performance on spinning disks is good, but top performance here is not the priority.
- Allow for effectively racing cache against network, so as to not wait serially.
Success Metrics
- Same hit rate as current cache, but do things in parallel.
- No on-disk i/o.
- Create telemetry for with-cache and without-cache. For top 50% cache should be faster than no cache, for low 50% cache should be faster than no cache.
API
API design goes here.
Locking
Locking plans go here. Clearly detail what locks the cache will have, and strategies to avoid lock contention in performance-critical situations.
On-Disk Layout
Clearly describe on-disk layout here.