Firefox HTTP cache v1 API disabled

Recently we landed the new HTTP cache for Firefox (“cache2”) on mozilla-central.  It has been in nightly builds for a while now and seems very likely to stick on the tree and ship in Firefox 32.

Given the positive data we have so far, we’re taking another step today to making the new cache official: we have disabled the old APIs for accessing the HTTP cache, so addons will now need to use the cache2 APIs. One important benefit of this is that the cache2 APIs are more efficient and never block on the main thread.  The other benefit is that the old cache APIs were no longer pointing at actual data any more (it’s in cache2) :)

This means that the following interfaces are now no longer supported:

  •  nsICache
  •  nsICacheService
  •  nsICacheSession
  •  nsICacheEntryDescriptor
  •  nsICacheListener
  •  nsICacheVisitor

(Note: for now nsICacheService can still be obtained: however, calling any of its methods will throw NS_ERROR_NOT_IMPLEMENTED.)

Access to previously stored cache sessions is no longer possible, and the update also causes a one-time deletion of old cache data from users’ disks.

Going forward addons must instead use the cache2 equivalents:

  •  nsICacheStorageService
  •  nsICacheStorage
  •  nsICacheEntry
  •  nsICacheStorageVisitor
  •  nsICacheEntryDoomCallback
  •  nsICacheEntryOpenCallback

Below are some examples of how to migrate code from the old to the new cache API.  See the new HTTP cache v2 documentation for more details.

The new cache2 implementation gets rid of some of terrible features of the old cache (frequent total data loss, main thread jank during I/O), and significantly improves page load performance.  We apologize for the developer inconvenience of needing to upgrade to a new API, but we hope the performance benefits outweight it in the long run.

Example of the cache v1 code (now obsolete) for opening a cache entry:

var cacheService = Components.classes["@mozilla.org/network/cache-service;1"]
                   .getService(Components.interfaces.nsICacheService);

var session = cacheService.createSession(
  "HTTP",
  Components.interfaces.nsICache.STORE_ANYWHERE,
  Components.interfaces.nsICache.STREAM_BASED
);

session.asyncOpenCacheEntry(
  "http://foo.com/bar.html",
  Components.interfaces.nsICache.ACCESS_READ_WRITE,
  {
    onCacheEntryAvailable: function (entry, access, status) {
      // And here is the cache v1 entry
    }
  }
);

Example of the cache v2 code doing the same thing:

let {LoadContextInfo} = Components.utils.import(
  "resource://gre/modules/LoadContextInfo.jsm", {}
);
let {PrivateBrowsingUtils} = Components.utils.import(
  "resource://gre/modules/PrivateBrowsingUtils.jsm", {}
);

var cacheService = Components.classes["@mozilla.org/netwerk/cache-storage-service;1"]
  .getService(Components.interfaces.nsICacheStorageService);

var storage = cacheService.diskCacheStorage(
  // Note: make sure |window| is the window you want
  LoadContextInfo.fromLoadContext(
    PrivateBrowsingUtils.privacyContextFromWindow(window, false)),
    false
);

storage.asyncOpenURI(
  makeURI("http://foo.com/bar.html"),
  "",
  Components.interfaces.nsICacheStorage.OPEN_NORMALLY,
  {
    onCacheEntryCheck: function (entry, appcache) {
      return Ci.nsICacheEntryOpenCallback.ENTRY_WANTED;
    },
    onCacheEntryAvailable: function (entry, isnew, appcache, status) {
      // And here is the cache v2 entry
    }
  }
);

 

There is a lot of similarities, instead of a cache session we now have a cache storage having a similar meaning – to represent a distinctive space in the whole cache storage – it’s just less generic as it was before so that it cannot be misused now.  There is now a mandatory argument when getting a storage – nsILoadContextInfo object that distinguishes whether the cache entry belongs to a Private Browsing context, to an Anonymous load or has an App ID.

(Credits to Jason Duell for help with this blog post)

NGC 7000, NGC 6974, IC 1318 a okolí + IR

NGC 7000, NGC 6974, IC 1318

NGC 7000, NGC 6974, IC 1318 + Infrared

 

Dvě téměř zapomenuté fotky z lokace jižně od Prahy, focené loni v létě v noci z 16. na 17. června. Velmi krátká noc, slunce definitivně zapadlo snad až před jedenáctou a po druhé už zase začalo svítat. Zato divokých psů a prasat v okolní vysoké trávě bylo požehnaně :)

 

Horní fotografie je jen viditelné světlo, dolní má modrý overlay v IR pásmu nad 742nm. Kvalita je sice mizerná, základ je vždy jen jedna fotografie, ale mě se to líbí.

 

Canon 30D, MC mod
Canon EF 35mm/F2
HEQ5, ustavena tentokrát driftovou metodou
Astronomik CLS-CCD: 1x600s @ F4.0, ISO 1000
Astronomik ProPlanet IR 742: 1x300s @ F4.0, ISO 1000
0x Flat/Dark/Bias
Zpracování v CR a PS

Headless Fedora 20 and VNC with autologin

“Oh no! Something has gone wrong” message is all what you get when you VNC to Gnome 3 in Fedora 20 on a box without any physical monitor attached to any of the video outputs with enabled autologin and screen sharing (vino).  There is an error in /var/log/messages ‘TypeError: this.primaryMonitor is undefined’ at /usr/share/gnome-shell/js/ui/layout.js:410.  I haven’t found a Fedora bug open for this.

You cannot also simply configure e.g. tiger-vnc because of other two bugs, one closed and one open preventing login screen from entering the password – as somebody would be pressing the entry key on and on.

I was not able to find a straight and simple fix unless I’ve hit this solution for Ubuntu, and ported it to Fedora 20:

  • #yum install xorg-x11-drv-dummy
  • put this content to /etc/X11/xorg.conf (you will probably need to create the file):

Section “Monitor”
Identifier “Monitor0”
HorizSync 28.0-80.0
VertRefresh 48.0-75.0
Modeline “1280×800”  83.46  1280 1344 1480 1680  800 801 804 828 -HSync +Vsync
EndSection

Section “Device”
Identifier “Card0”
Option “NoDDC” “true”
Option “IgnoreEDID” “true”
Driver “dummy”
EndSection

Section “Screen”
DefaultDepth 24
Identifier “Screen0”
Device “Card0”
Monitor “Monitor0”
SubSection “Display”
Depth 24
Modes “1280×800”
EndSubSection
EndSection

You can then VNC to port :0 and you will be logged in directly without a need to enter the user password.  I suggest SSH tunneling.

 

New Firefox HTTP cache now enabled on Nightly builds

Yes, it’s on!  After a little bit more than a year of a development by me and Michal Novotný all bugs we could find in our labs, offices and homes were fixed.  The new cache back-end is now enabled on Firefox Nightly builds as of version 32 and should stay like that.

The old cache data are for now left on disk but we have handles to remove them automatically from users’ machines to not waste space since it’s now just a dead data.  This will happen after we confirm the new cache sticks on Nightlies.

The new HTTP cache back end has many improvements like request prioritization optimized for first-paint time, ahead of read data preloading to speed up large content load, delayed writes to not block first paint time, pool of most recently used response headers to allow 0ms decisions on reuse or re-validation of a cached payload, 0ms miss-time look-up via an index, smarter eviction policies using frecency algorithm, resilience to crashes and zero main thread hangs or jank.  Also it eats less memory, but this may be subject to change based on my manual measurements with my favorite microSD card which shows that keeping at least data of html, css and js files critical for rendering in memory may be wise.  More research to come.

Thanks to everyone helping with this effort.  Namely Joel Maher and Avi Halachmi for helping to chase down Talos regressions and JW Wang for helping to find cause of one particular hard to analyze test failure spike.  And also all early adopters who helped to find and fix bugs.  Thanks!

 

New preferences to play with:

 

browser.cache.disk.metadata_memory_limit
Number of kBs we reserve for keeping recently loaded cache entries metadata (i.e. response headers etc.) for quick access and re-validation or reuse decisions.  By default this is at 250kB.
browser.cache.disk.preload_chunk_count
Number of data chunks we always preload ahead of read to speed up load of larger content like images.  Currently size of one chunk is 256kB, and by default we preload 4 chunks – i.e. 1MB of data in advance.

 

Load times compare:

Since these tests are pretty time consuming and usually not very precise, I was only testing with page 2 of my blog that links some 460 images.  Media storage devices available were: internal SSD, an SDHC card and a very slow microSD via a USB reader on a Windows 7 box.

 

[ complete page load time / first paint time ]

SSD
Cache versionFirst visitCold go to 1)Warm go to 2)Reload
cache v17.4s / 450ms880ms / 440ms510ms / 355ms5s / 430ms
cache v26.4s / 445ms610ms / 470ms470ms / 360ms5s / 440ms

 

Class 10 SDHC
Cache versionFirst visitCold go to 1)Warm go to 2)Reload
cache v17.4s / 635ms760ms / 480ms545ms / 365ms5s / 430ms
cache v26.4s / 485ms1.3s / 450ms530ms / 400ms*5.1s / 460ms*

 

Edit: I found one more place to optimize – preload of data sooner in case an entry has already been used during the browser session (bug 1013587).  We are winning around 100ms for both first paint and load times!  Also stddev of first-paint time is smaller (36) than before (80).  I have also measured more precisely the load time for non-patched cache v2 code.  It’s actually better.

Slow microSD
Cache versionFirst visitCold go to 1)Warm go to 2)Reload
cache v113s / 1.4s1.1s / 540ms560ms / 440ms5.1s / 430ms
cache v26.4s / 450ms1.7s / 450ms710ms / 540ms*5.4s / 470ms*
cache v2 (with bug 1013587)--615ms / 455ms*-

* We are not keeping any data in memory (bug 975367 and 986179) what seems to be too restrictive.  Some data memory caching will be needed.

 

“Jankiness” compare:

The way I have measured browser UI jank (those hangs when everything is frozen) was very simple: summing every stuck of the browser UI, taking more then 100ms, between pressing enter and end of the page load.

 

[ time of all UI thread events running for more then 100ms each during the page load ]

SSD
Cache versionFirst visitCold go to 1)Warm go to 2)Reload
cache v10ms600ms0ms0ms
cache v20ms0ms0ms0ms

 

Class 10 SDHC
Cache versionFirst visitCold go to 1)Warm go to 2)Reload
cache v1600ms600ms0ms0ms
cache v20ms0ms0ms0ms

 

Slow microSD
Cache versionFirst visitCold go to 1)Warm go to 2)Reload
cache v12500ms740ms0ms0ms
cache v20ms0ms0ms0ms

 

All load time values are medians, jank values averages, from at least 3 runs without extremes in attempt to lower the noise.

 

1) Open a new tab and navigate to a page right after the Firefox start.

2) Open a new tab and navigate to a page that has already been visited during the browser session.