Real data and musings on the performance of networks, servers, protocols, and their related folks.

Wednesday, April 25, 2012

Making Firefox Search Snappier

The Firefox 15 development window just opened and I checked into inbound a cool
feature that had been sitting in my queue for a little while. Let's see if it sticks!

The
feature basically lets non-network code hint to the networking layer
that it will probably send a http transaction to a particular site soon,
but it isn't ready to do so yet. The network code can take the hint and
begins to setup a TCP and (if necessary) SSL handshake right away
because these are high latency operations.

The primary initial
user of this is the search box in firefox. When you focus on that box we
will probably make a connection to the search provider right away. Simultaneously with this you type your search terms - when your search is ready (or
partly ready if you are using search suggestions) it can be submitted to the search service without any waiting for network setup.

This can be a significant win. The average Internet round trip time is about 100ms (there is a lot of variation in this). It takes 1 RTT to setup TCP and (likely) 2 more for SSL. 300ms is a notable pause, but overlapped in the background it essentially becomes free resulting in snappier searches that still use a secured transport. If you're using a SPDY enabled search provider such as google or twitter, this is done over SPDY, so the one TCP session now established will be able to carry all of your search results - no more setup overhead to worry about with additional parallel connections etc..

The other user of this feature that got checked in as part of this merge is actually internal to the networking code just before the cache I/O is done. The amount of time it takes to check the disk cache is extremely variable - afaict generally its pretty fast but the tail can be really awful depending on hardware, other system activity, OS, etc.. So we overlap the network handshakes with this activity that figures out the values of the If-Modified-Since (etc..) request headers.

There is an IDL for providing the hint (nsISpeculativeConnect) - so if you can think of other areas ripe for this kind of optimization let's get to it!

[The best place for comments is probably here: https://plus.google.com/100166083286297802191/posts ]