To date the SW Cache implementation has only had very basic testing done. At most a handful of requests at a time. Before releasing this on the world we should verify it doesn't fall over on more realistic workloads. I expect most of the issues will be in the DB schema. I have some ideas to improve things there, but want measurements to verify they are worth it: Ideas: * De-normalize VARY header info into a boolean column on each Cache entry. This avoids having to touch the headers table to determine if an entry needs the more complex VARY matching logic. * Modify queries that read entries to use bulk operations. This would minimize index lookups. These are fast, but still take O(log n) time each.

See bug 940237 comment 110 for many excellent suggestions to investigate.

(ni'ing myself to continue my investigation I started on bug 940273) Note that comment 1 has a bug number typo, :mak's feedback is on bug 940273 comment 110.

We should do this after the prefixMatch feature is removed in bug 1130452. This will make it much easier to use hashes for the URL and avoid TEXT column indices.

Note that performance testing and optimization here will include FileUtils code as well.

We should steal ideas from the IDB optimization bug.

Test measurements of different improvements in IDB: https://docs.google.com/a/mozilla.com/spreadsheets/d/1KbcxgvkCeeuFArrnyA6qrvcuA_HWjWT-X5rn_nNJbIk/edit#gid=1280969721

I converted CacheStorage keys to blobs to fix a functional issue in bug 1153245. We should consider doing the same for other strings since we don't actually need fancy string encoding.

FYI, OpenDatabaseWithFileURL() need not always created shared cache connections; you can pass the "cache=private" option to get an unshared connection. (e.g. http://mxr.mozilla.org/mozilla-central/source/dom/indexedDB/ActorsParent.cpp#3556)

I'm not working on this at the moment. We could do some more profiling, but this has been shipped for a while without any perf issues reported.

clearing old need-info