Necko/Cache/Plans

New Cache Plans

People

We have decided to rewrite the HTTP disk cache.

The design team will be responsible for this page

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

• All APIs should be async. No main-thread locking or i/o at all.
• A crash should not invalidate the entire cache.
• 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.
• 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 to 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.