|
|
| Line 1: |
Line 1: |
| =Goals=
| | This page has been merged into [[Necko/MobileCache]]. |
| | |
| ==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)
| |
| | |
| 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=
| |
| | |
| ==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)
| |
| | |
| ==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.
| |
| | |
| ==Performance (wifi / cell)==
| |
| | |
| 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
| |
| | |
| ===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].
| |