Revision as of 16:17, 11 March 2013

New Cache Plans

We have decided to rewrite the HTTP disk cache.

Design team:

Implementation team:

All APIs should be async.
A crash should not invalidate the entire cache.
Don't over-optimize on-disk storage, use one file per entry to let OS optimize.
Support GZIP. Meta-data should say whether a file is gzip'd or not, can be turned on and off without causing corruption. Pass through files gzip'd from the network.
Version API for the cache so we can update easily.
Make use of fallocate.
Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API.

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.

API design goes here.

Locking plans go here. Clearly detail what locks the cache will have, and strategies to avoid lock contention in performance-critical situations.

Clearly describe on-disk layout here.

@@ Line 21: / Line 21: @@
 * All APIs should be async.
 * A crash should not invalidate the entire cache.
+* Don't over-optimize on-disk storage, use one file per entry to let OS optimize.
+* Support GZIP. Meta-data should say whether a file is gzip'd or not, can be turned on and off without causing corruption. Pass through files gzip'd from the network.
+* Version API for the cache so we can update easily.
+* Make use of fallocate.
+* Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API.
 == Performance Goals ==