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 ]
Real data and musings on the performance of networks, servers, protocols, and their related folks.
Wednesday, April 25, 2012
Monday, April 23, 2012
Welcome Jiten - Building a Networking Dashboard
There are many awesome things about the Firefox networking layer. However realtime visibility into what its doing is not on that list.
Thanks to Google Summer of Code, Jiten Thakkar is going to work on that problem this summer. Jiten is already a card carrying Mozillian with code commits in several parts of Gecko and I'm excited to have him focused on necko and an add-on for the next few months.
We hope to learn what connections are being made, how fast they are running, what the DNS cache looks like, how often SPDY is used, and all manner of other information that will aid debugging and inform optimization choices. Maybe even icing on the cake ssuch as in-browser diagnostic tools (e.g. Can I tcp handshake with an arbitrary hostname? How about HTTP? How about SSL?) to round things out.
Good Stuff!
Thanks to Google Summer of Code, Jiten Thakkar is going to work on that problem this summer. Jiten is already a card carrying Mozillian with code commits in several parts of Gecko and I'm excited to have him focused on necko and an add-on for the next few months.
We hope to learn what connections are being made, how fast they are running, what the DNS cache looks like, how often SPDY is used, and all manner of other information that will aid debugging and inform optimization choices. Maybe even icing on the cake ssuch as in-browser diagnostic tools (e.g. Can I tcp handshake with an arbitrary hostname? How about HTTP? How about SSL?) to round things out.
Good Stuff!