Confirmed users
96
edits
Necko/MobileCache: Difference between revisions
Jump to navigation
Jump to search
→Collecting data to figure out why HTTP disk cache is slow on fennec
Todesschaf (talk | contribs) |
Todesschaf (talk | contribs) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
Feel free to add comments in this wiki: put your name on them so we can followup. I'll try to scrub obsolete comments once they're resolved (but feel free to do that yourself, too): jduell. | Feel free to add comments in this wiki: put your name on them so we can followup. I'll try to scrub obsolete comments once they're resolved (but feel free to do that yourself, too): jduell. | ||
Also see [[Necko/Cache|Cache Architecture]] | Also see [[Necko/Cache|Cache Architecture]]. | ||
== Theories about why the mobile HTTP disk cache is slow == | == Theories about why the mobile HTTP disk cache is slow == | ||
| Line 16: | Line 16: | ||
== Collecting data to figure out why HTTP disk cache is slow on fennec == | == Collecting data to figure out why HTTP disk cache is slow on fennec == | ||
So far we only have aggregate data (tp4 runs) that shows the cache is often a perf loss on mobile - see [[ | So far we only have aggregate data (tp4 runs) that shows the cache is often a perf loss on mobile - see [[Necko/MobileCache#Effect_of_Cache_Size]]. | ||
* bjarne: note that this test is limited in that it cyclically loads a limited pageset, and it keeps the memory-cache at 1Mb. Effectively it says "When loading a relatively small pageset over-and-over again on mobile, a 1Mb memory-cache is often more efficient than a disk-cache." Given that the cache-service prefers using a disk-cache over a memory-cache, and the memory-cache uses a more sophisticated replacement-algorithm than the disk-cache (see {{bug|648605}} and {{bug|693255}}) this is not surprising. To be more conclusive we need results from running this test with the memory-cache turned off. | * bjarne: note that this test is limited in that it cyclically loads a limited pageset, and it keeps the memory-cache at 1Mb. Effectively it says "When loading a relatively small pageset over-and-over again on mobile, a 1Mb memory-cache is often more efficient than a disk-cache." Given that the cache-service prefers using a disk-cache over a memory-cache, and the memory-cache uses a more sophisticated replacement-algorithm than the disk-cache (see {{bug|648605}} and {{bug|693255}}) this is not surprising. To be more conclusive we need results from running this test with the memory-cache turned off. | ||
We have run some tests with a slightly modified tp4m to better test cache performance. See [[Necko/MobileCache/Tp4m]] for more details. | |||
We need much more detailed information about what's going on. So we need to write and run some microbenchmarks that will test our current theories and quantify what (if any) performance cost they may have. For further details please visit [[Necko/MobileCache/MicroBenchmarks]]. | We need much more detailed information about what's going on. So we need to write and run some microbenchmarks that will test our current theories and quantify what (if any) performance cost they may have. For further details please visit [[Necko/MobileCache/MicroBenchmarks]]. | ||
| Line 137: | Line 139: | ||
****Is Tp good enough for testing this? Bug 661900 indicates it isn't (Geoff Brown made some modifications to make it better) | ****Is Tp good enough for testing this? Bug 661900 indicates it isn't (Geoff Brown made some modifications to make it better) | ||
*What size disk caches do other mobile browsers use? | *What size disk caches do other mobile browsers use? | ||
**Android Browser | **Android Browser - Appears to be 6MB according to the source code mirrored at https://github.com/android/platform_frameworks_base/blob/master/core/java/android/webkit/CacheManager.java#L60 | ||
**Chrome Mobile (especially interesting given Chrome's similar disk cache implementation) | ***On a rooted Froyo phone, you can see the cache is stored at /dbdata/databases/com.android.browser/cache/webviewCache. Experiments confirm the 6MB capacity. Each entry is stored as received from the network, in its own file (there are no block files). The maximum entry size is about 2MB (larger files are not stored). | ||
**Opera Mobile (not the crappy "download pre-rendered pages" version) | **Chrome Mobile (especially interesting given Chrome's similar disk cache implementation) - Can't find anything on this (yet), hopefully will get easier once ICS is released and we can (hopefully) see the config on a running mobile chrome. | ||
**Safari Mobile (not a direct competitor, but maybe useful data point since it's a rather common mobile browser) | **Opera Mobile (not the crappy "download pre-rendered pages" version) - 10000K according to opera:config (this is 1/2 what the desktop version has by default). Note that Opera also has a separate media cache which defaults to 10x the regular disk cache size. | ||
**Safari Mobile (not a direct competitor, but maybe useful data point since it's a rather common mobile browser) - The internet says it doesn't have one at all | |||
**Dolphin HD (another popular android browser) - The internet conflicts, but it appears to be either 20MB or 40MB | |||
==Mobile Team's Goals== | |||
===Quickly restore webpages after fennec restarts=== | |||
On Android, when Fennec is placed in the background, we have a high chance of being killed by the OS. This is so that foreground applications have more memory available and does improve system performance. For applications, this means that they need to store out state before they die. Currently, we do not do an adequate job of saving state out resulting in a pretty terrible experience when you 'switch back' to Fennec. | |||
* When you say "killed", are we gracefully shutting down? If not we're probably blowing away the cache (we do that unless we quit cleanly). jduell | |||
** "Killed by the OS" is not shutting down gracefully. (mfinkle) | |||
*Can we use the onPause event to flush _CACHE_MAP_ to disk, in the hopes of being able to do that before we get killed? (hurley) | |||
What we need to do is to be able to 'pin' all content that has been currently loaded, then when Fennec restarts have away to just load that from cache without issuing a 302. | |||
* What do you mean "without issuing a 302"? If the content is in cache (which it's likely to be if if was loaded recently, which seems likely in a low-tab environment like fennec), you'll just load it from cache, no? jduell | |||
===AppCache/Pinning=== | |||
Similar to the system I mentioned in (1), we need a way to pin content for long periods of time. The idea is to load that page into the browser, and somehow mark it so that it will not be evicted. The Fennec application would be in control of when a page (and related content) is pinned and when it can be evicted. | |||
* The general solution to this is cache priorities, but we could probably knock off a faster solution that allows simply marking a cache entry as "pinned": it would of course be up to you to make sure you eventually evict these when needed. Open a bug and cc me if you want it. jduell | |||
The reason we need something like this is that Stuart's has been discussing replacing large parts of the Fennec UI with content that is served from mozilla.com. For example, the "awesome screen" in Fennec might just be a https://home.mozilla.org load. When Fennec starts up, that is the first thing that they will see -- so having no network latency hit would be required. | |||
* A faster (but less modify-able on the fly) way to do this is presumably to bundle a web page with fennec and load that (as a resource:// URL?) rather than pin in the cache. But then you can't simply update the web server to modify the page--it would be fixed until the browser is updated. But note that unless you cache the home page with a fixed expiration that doesn't require validation, we'll wind up hitting the network to revalidate, which is probably not a win. jduell | |||
==Issues Raised by Mobile Team== | |||
===Writes on the main thread=== | |||
Any panning performance issue is not acceptable. We know that writing on the main thread in the parent process will cause some devices to block. If the user is doing a pan during this write, it will appear that the world has frozen. | |||
* AFAIK the cache no longer does any writes on the main thread. If you know otherwise, please let the necko team know. jduell | |||
** We have no data that says main thread I/O is happening. This is just a pre-req, not blame of a known situation. If I/O is not on main thread, the world is a better place. (mfinkle) | |||
**All data points to no writes happening on the main thread (hurley) | |||
===Limited FS space=== | |||
Cacheing on the internal memory of a device will be limited by its small size. For example, my Nexus S (which is a newer higher end Android device running 2.3) has 16gb of storage (iNAND). 1gb is used for internal storage. The other 15gb (or so) is used as external storage. Interestingly (and somewhat unrelated), you can't remove the external memory physically. However, you can mount the memory via USB on your PC. In this case, the external memory is not available to applications | |||
I think in the short term, we just disable the cache if the user doesn't have an external. We also should ensure that we don't die if the disk cache location because unavailable while we are running. | |||
Maybe in the longer term, we could investigate two disk cache locations, but I don't think I care that much about it now. | |||
For every web page retrieved over SSL, the cache saves a complete copy of the certificate chain (usually a few KB) with the metadata of the page. Reducing this overhead by writing each cert chain to disk just once might become worthwhile. | |||
PSM caches SSL intermediate certificates, and can be set to cache some CRLs in some configurations, and will probably cache OCSP responses and many more CRLs soon. If the PSM cache isn't regulated, it could easily reach several (dozens of ) megabytes because of the CRLs. | |||
What kind of storage space do we want to use in the various situations/what has been deemed an "acceptable" maximum cache capacity? We currently use up to 1G on desktop (depending on amount of free space on disk). Keep in mind, smaller caches will be more likely to evict entries that might be useful later on. (hurley) | |||
===Performance (wifi / cell) (As measured before I/O was off the main thread)=== | |||
I do not have alot of evidence supporting this, but I wanted to mention it. I did some simple experiments enabling the disk cache on wifi and on a cell (3g) network. What is interesting, is that on a fast network, the disk cache made no different and may have slightly hurt page load perf. While on a 3g network, it was a noticeable (~13% iirc) win. This isn't conclusive, but we should investigate this and determine if runtime-switching of the disk cache makes any sense. | |||
* We should investigate why it's a loser on wifi and fix it. jduell | |||
** It doesn't seem to be a loser on wifi now that I/O is off the main thread (hurley) | |||
====Effect of Cache Size==== | |||
Tested the affect of changing the cache size on Tp pageload results. Galaxy Tab filesystem is so bad, cache is never a win. Nexus One has a sweet spot around 4MB - 6MB on wireless (3g), where the win is just over 9%. | |||
[[File:Disk-cache-size-vs-tp.png]] | |||
These tests started from {{bug|645848}} (see comment 5). I collected some more data using different cache sizes and put the results in a [https://docs.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0AjcsKAH2v2E_dDc0ZlFfWVJqWUpaMXdLTE1TUFdlN1E&output=html Google Spreadsheet]. | |||