Update: Tested docs on FFX 13 with 25 docs tabs, confirmed the X-Firefox-Spdy response header was showing up in responses. There were no obvious signs that our 'sharding' technique was disagreeing with SPDY in any noticeable way, so no action is required at this time.
I have no easy way of knowing whether it's managing to reuse the same SPDY connection for all the tabs or whether it's making new ones. I'd point out though that if you'd like it to be possible for us to adopt a more efficient networking strategy where SPDY is available (ie not doing this sharding) we would need to have some sign that SPDY was in use. I gather that a browser version check isn't sufficient, as the use of SPDY can be prevented by proxies and whatnot. Thanks for your help! Regards, -Dave On Wednesday, May 30, 2012 3:06:58 PM UTC-5, [email protected] wrote: > On Thursday, May 24, 2012 1:54:10 PM UTC-5, Patrick McManus wrote: > > On Thu, 2012-05-24 at 08:54 -0700, [email protected] wrote: > > > issue. I'm not sure what that number is in Firefox right now, but at > > > least traditionally it's been lower than we've been comfortable with. > > > > it's 6 - same as chrome and ie. > > > > > To get around the limit, we open each hanging GET to a different > > > numbered subdomain of docs.google.com. > > > > "sharding" we call it. one of the goals for spdy is to allow enough > > parallelism that you don't need to do that - cause it really sucks in > > many ways :) > > > > > When we first tried this technique in Chrome, it disagreed with their > > > SPDY implementation. When SPDY in Chrome is active, the per-origin > > > connection limit is lifted to a much higher number, the maximum stream > > > count on the SPDY connection. > > > > In firefox we look at it like this: you still have the limit of 6 > > connections its just that you can do parallel work on a single > > connection so we are incented to not use them all. and if everything is > > well established its true you will only be using one of them but there > > are times you will have more than 1 connection open and active to the > > same host. (but probably only 1 of them is starting new work). > > > > There is also an ip pooling concept that is used to automatically > > de-shard. (like I said, sharding sucks - and once you have spdy's > > parallelism you don't need it anymore). For two hosts to be de-sharded > > into one they must share the same IP address and have SSL certs that > > cover the "redirected" host (e.g. *.google.com). > > It was almost a year ago now that we encountered the issue in Chrome, and it > hasn't been revisited since. Either something about our case was defeating > Chrome's IP based de-sharding, or it hadn't yet been introduced. Google's > serving system uses DNS for load balancing, so there's a decent chance these > different 'shard' DNS names sometimes return different IP addresses. Right > now the DNS seems to be showing stable IP addresses for them, but I'm not > sure that's to be relied on. For example, try repeatedly resolving > www.google.com, you'll get a different answer each time. > > > You should be able to continue to use the sharded names without a > > problem in a spdy context - spdy will basically undo that for you in > > firefox. (there are some race conditions here, because 1] we can't > > unshard in a non-spdy context and, 2] we don't serialize all > > connections, and 3] we can't know if the host is spdy or not without a > > connection. So sometimes sharding still happens in a spdy context, but > > we try and shut down those connections and move new transactions to the > > preferred host as quickly as we can.) > > I will experiment and see how SPDY/Firefox in our case. Is there any way to > tell if two requests shared a SPDY connection, so I can know whether the IP > based desharding is working? > > > > may have completely different characteristics. I haven't actually > > > tested our solution on Firefox/SPDY yet, so I'm not sure. > > > > I'm not sure either, because to be honest I can't quite follow your > > story of where the failure happened on chrome. I have the gist of it - > > but not all the specifics. If its important please try again in step by > > step detail. I'm interested. > > I may not be able to give you as much detail as you'd like, because I'm a > webapps guy and not a browser guy, and I just don't know it. I'll try, but > it's going to be a little phenomenological and probably no longer correct. > There were two connection limits in play for us. There was the well known > limit on how many domains we could connect to for non-SPDY connections, and > there was a limit on how many SPDY connections Chrome was willing to > establish in total. That second limit was of the order of 20, and each > connection to a shard domain name was consuming one. When that 'pool' or > whatever it was underran the behavior was even worse than when the regular > connection limit was exceeded. This was because each of these SPDY > connections would speculatively stay open for some period of time after the > last HTTP request was performed on it, in case another one came along. This > meant the pool remained depleted even after the docs tabs using the > connections had been closed. Yo u'd open 20 docs tabs, close them all again, and then find that you couldn't open any more because this 'SPDY pool' wouldn't give you any connections. > > We in docs were stuck at that point, because it wasn't safe to use or not use > the shard domains. If we used them, the above scenario unfolded when SPDY > was active. If we didn't, we'd overrun the regular connection limit when it > wasn't. Luckily there happened to be this internal JS API there to say if > SPDY was active, so we used it to determine which strategy to adopt. It > remains in place today, as even if any bugs in the SPDY behavior have been > fixed it's still nice to make the best use of SPDY we can. > > > > to work out whether I've conducted a valid test - hopefully the use > > > of SPDY at least shows up in firebug or some other debugging tool? > > > I'd hate to be getting out my packet sniffer :-) > > > > on FF, there is a fake response header injected into each transaction > > that was done over spdy: X-Firefox-Spdy.. you can't get to it with > > normal priv JS, but you can see it in the developer tools > > (ctrl-shift-k), with the live http headers add-on, or with firebug. > > Thanks, will look out for it. > > > > The use of random subdomains to circumvent connection limits has > > > costs. DNS lookups are needed, and it defeats SPDY's ability to > > > establish multiple http connections over one TCP connection. > > > > like I said, firefox and chrome (iirc) try and undo the sharding > > automatically. The costs are worse than you state - its bad for > > congestion control, bufferbloat, resource prioritization, and fast tcp > > loss recovery too. The DNS aspect is one place where this > > auto-unsharding doesn't help. > > We don't do it because we like it, I promise you. The pain involved in > keeping it running on all browsers is considerable. We aren't ready for > websocket yet, but that day will come before long. > > > if we were going to put transport information (protocol, version level, > > etc.. ) into the dom I'd want to take a cue from boris or jonas on where > > and how. > > Will get back to you with experimental results on how necessary it is. Even > if retaining sharding still works it seems it's not the most efficient course > however. I could make use of this information if it were there to increase > networking efficiency. While obviously a standard solution would be best, > this is pretty obscure territory, this isn't something many web devs will be > interested in. A non-standard solution would probably serve for a long time, > maybe forever. _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
