Status Update: January 23

Progress

  • Began working towards this quarter’s main-thread IO reduction goal by creating an asynchronous version of nsIContentPrefService::getPref. We currently use getPref every onLocationChange to check if there’s a page zoom setting saved for the site being loaded. This check happens on every page load and tab switch and sometimes multiple times for each (f.e. loading a link in new, focused tab fires onLocationChange when switching to the new tab, loading about:blank in that tab and then loading the final URL – arguably we can be a bit more intelligent about filtering these) and if it’s slow to return, the UI will be blocked while we wait for it. The downside to doing this is that in the cases where we’d previously be stuck waiting, unzoomed content will continue loading and then be set to the desired zoom level once we’ve gotten a result – sometimes leading to a distracting jump in size if the content’s already visible, but I think that’s definitely a hit worth taking. The API changes are covered in bug 539907, frontend in bug 541779.
  • While working on the above, I ran across a few tests that check that entering and exiting print preview doesn’t interfere with the zoom level. Print preview works in a way that makes it rather difficult and fragile to do what I want, so I’ve decided to take advantage of our new ability to clone documents and make print preview open in a separate window. I’ll be posting a followup later this week with some builds to try out. Stay tuned!

This Week in Perf

Progress

  • Posted some findings to bug 496217. Turns out we will only load the spell check dictionaries during startup if the user’s homepage or restored session contain spell check enabled inputs. I’ve posted some possible next steps in the bug, but the best solutions will likely lead to us partially forking and maintaining our own copy of Hunspell.
  • Spent some quality time with gdb and a bunch of test cases trying to catalog all the cases in which we touch NSS on the startup path for bug 441355. I’ll probably be posting those findings this weekend.

Next Steps

Over One Billion¹ Served

A little over a year ago, some of my fellow mozillians and I decided we wanted to have a place to host websites and e-mail, stick off-site backups, and perform other disk or CPU intensive things not typically permitted in a shared hosting environment. After  exploring a few options, we decided to split a dedicated server and eventually settled on Voxel as our host.

Of course, with just a few low-traffic websites, backups, and an SSL cert survey or two, we typically found ourselves far under our monthly included bandwidth.  Not wanting to leave our investment underutilized, we took advantage of our server package’s included access to the VoxCAST CDN and put it to work as a Mozilla mirror.

Mozilla’s Bouncer mirror management system distributes traffic proportionally, based on assigned weights. Since we only had a small amount of bandwidth to offer compared to most of the other mirrors in the system, we usually kept our mirror’s weight low to avoid eating up our entire bandwidth allotment. Firefox 3.0.11’s release happened to line up with the end of a billing period where we had some extra bandwidth leftover, so we decided to burn through it by increasing our weight dramatically. Our traffic quickly climbed from a few Mbps to over 3Gbps, which managed to grab the attention of the folks in the Voxel NOC. They pinged us to make sure we were aware of the situation, and after learning what the traffic was being used for and a few discussions with Reed², they generously offered to donate a substantial amount of bandwidth to be used by the Mozilla mirror network.

Everything got setup just in time for the Firefox 3.5 release, and in the four months since, we’ve served more than 1.3 petabytes of updates, installers, and add-ons. And all of that coming from a single origin server that, thanks to VoxCAST, is so lightly loaded it’s able to run a BOINC client most of the time!

Graph of outbound mirror traffic June 28th - October 31st: Maximum: 10.83Gb/s Average: 1.00Gb/s Total: 1.34PB

Graph of requests per second June 28th - October 31st. Max: 2904.79 Avg: 269.98

As impressive as that is, it’s worth noting that this mirror only accounts for (as of this writing) just over 25% of the total available capacity. Mozilla wouldn’t be able execute releases and updates for all its products with the same level of quality and reliability we all currently enjoy thanks to the behind-the-scenes and often unsung heroes of our mirror network.

So to those who volunteer your time, machines, and bandwidth to make every release and the day-to-day a success, thank you. Mozilla simply wouldn’t be able to do it without you.

¹ Megabytes

This Week in Perf

Progress

Next Steps