Hi All, We've reached a state of basically interoping with some performance limitations so I wanted to share an update on how things are going.
First, stuff works. You can try it and report interesting cases (i.e. breakage, extreme good or bad performance) I've kicked off try builds just now here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mcma...@ducksong.com-f4af1bdeb506. Actually, I only know first hand that linux64 works. Remember, it is a first look. be gentle but sites to look at are a great help. It's still early. The patch is here http://www.ducksong.com/mozilla/spdy/spdy.001.090911.txt . It has Adam Langley's NPN patch for NSS inlined into it for the time being. I gave up on the hg repo for now - it was making my life harder in some ways. If you connect to the SSL version of most google properties (google plus, gmail, gcal, encrypted.google.com for search, most things other than youtube) you will use NPN and automatically negotiate spdy. Google analytics also uses spdy, so if general websites have have https:// links to analytics it will use them too - I've seen this pop up quite often. It interops with at least one non google server implementation too. It is preffable (search for spdy in about:config), but in these out of tree patches I just have it turned on for convenience. There is lots of good telemetry, look at about:telemetry (get the addon, set the pref, search for spdy on the about page). The usual HTTP log has the nitty gritty. There are a couple of significant things not implemented yet. The most important is "Alternate-Protocol". Think of that as a conditional redirect from http to https only if the client supports spdy. (it actually is an implicit redirect for future transactions - kind of like hsts). That lets people deploy spdy using http references instead of https ones so that only the spdy people use ssl (presumably a performance argument). I also don't implement server push yet. I'd like to get together with some folks and discuss exactly what it means especially wrt the cache. AFAIK there are no significant server push resources on the Internet today but multiple folks say they do intend to deploy it in the future. (I asked on spdy-dev). We can do this implementation separately from the main one without a problem, and I think that's the right thing to do. The other serious limitation with the implementation is in my ham fisted attempts to integrate SSL_LastHandshake() onto the SSL thread. That went poorly. I hate the SSL thread :). To put it kindly, I made a giant mess of it and don't regard the implementation as anything other than a place holder that mostly sort of works so I could get on to spdy proper. Brian, I want to spend some time with you next week figuring out the robust way to get the NPN info from the handshake before starting the HTTP/Spdy state machine. Jason - I don't think spdy has any implications for e10s but we should talk about that. Next steps - measure, test, improve stuff, repeat. I love that part and have just started it in the last day. So there are tons of things to improve and understand, no doubt - so I'm not making any general performance claims about the code in this email. I just haven't looked at it closely enough yet. One interesting case that I'm starting to look at is a celebrity posting on google plus with hundreds of comments: https://plus.google.com/108176814619778619437/posts/4Q8zan6JM2o . It also looks a lot like a facebook page: 384 resources, 373 of which are small jpg images. That seems like something that should be in spdy's wheelhouse. I've found a problem with the parallelism (for some reason the resources are added to be parallel in the spdy state machine out of the connection manager very quickly, but the requests don't make it to the network for a quite a while..), so right now most of the benefit comes from using fewer handshakes (the parallelism and reduced connection count are really the main two performance boosts of SPDY). The page is sharded over 4 primary hosts (plus 2 others for meta data) which means ~25 SSL handshakes to load it without spdy and just 6 with spdy. This can reduce the load time on even a low latency network from 12 seconds to ~3.5 which is great - but when you nav to other pages in the site persistent connections kick in and the handshake benefit goes away of course. _______________________________________________ dev-tech-network mailing list dev-tech-network@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-network
