Re: multiplexing -- don't do it

Responding to Ross and Brian's posts mainly here...

 

I agree that increasing concurrent connections will increase the burden on web servers and that is a serious issue for sure but since so many sites are already working around the 6 per domain limit via sharding, most site owners are willing to accept higher numbers of TCP connections if it results in faster page loads. Prevalence of domain sharding is a kind of vote in the direction of increasing the per domain limit.

Transparency:

·         SPDY compresses HTTP headers using an LZ history based algorithm, which means that previous bytes are used to compress subsequent bytes. So any packet capture that does not include all the traffic sent over that connection will be completely opaque -- no mathematical way to decode the HTTP. Even with all the traffic, a stream decoder will be a tricky thing to build b/c packets depend on each other.

·         Loss of transparency impacts intermediary devices (reverse proxies, caches, layer 7 switches, load balancers) as much as it does packet capture analysis. For load balancing, multiplexing requires maintaining state from one request to the next so individual object requests from a given user will need to be handled by the same de-multiplexing server.

 In general, increasing session orientation reduces the scalability of the overall service. Also, failover is less graceful as a load balancer will want to be more sure that the previously used server is in fact unavailable before routing to a new server.

·         SSL kills transparency at the network level completely but also I think that SSL should be considered as an orthogonal thing to performance. So that site owners can make a decision based on the cost, security, performance tradeoffs of going to all encrypted traffic. So while I agree it's related, it seems like we have to consider these things independently.

 

Increased Object Processing Latency:

·         Multiplexing requires that objects are encoded serially -- encode (Object1), encode (Object2), encode (Object3) -- and then decoded in that same order.

 On a multi-core server, the three objects arrive truly concurrently, but due to multiplexing Object2 and Object3 will need to wait while Object1 is encoded. For SPDY, that encode step involves running an LZ-type coding function including searching the recent bytes for matches so even on an unloaded server this can add ~milliseconds of latency.

·         Multiplexing creates the need for session state. Access to this state needs to be synchronized, thread synchronization reduces parallelism and so impacts server scalability and per object latency.

·         CPU gains are increasingly achieved by adding cores and not making existing cores go faster. So processes that can run concurrently are friendly to these advances (such as increasing concurrent TCP connections) and multiplexing goes in the opposite direction -- requiring thread synchronization and so increasing serialization, and context switching.