
Not as SPDY as You Thought - muriithi
http://www.guypo.com/technical/not-as-spdy-as-you-thought/
======
justinschuh
This was on HN eight months ago, when the post was actually made. And the
takeaway is pretty clear, you probably won't see a benefit in using SPDY in
front of a site optimized in ways that don't take advantage of SPDY's
strengths. If you want to see big improvements with SPDY (like Google does)
then you need to adjust how you're serving your resources. Resource
prioritization is a perfect example of this:
[https://insouciant.org/tech/prioritization-is-critical-to-
sp...](https://insouciant.org/tech/prioritization-is-critical-to-spdy/)

~~~
monsterix
Seconded. Might as well look at our experience using SPDY over Nginx and its
performance/impact etc.: [http://blog.bubbleideas.com/2012/08/How-to-set-up-
SPDY-on-ng...](http://blog.bubbleideas.com/2012/08/How-to-set-up-SPDY-on-
nginx-for-your-rails-app-and-test-it.html)

------
ck2
[http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-
as-...](http://www.belshe.com/2012/06/24/followup-to-not-as-spdy-as-you-
thought/)

------
starik36
Like others said, an old post. To be sure, he is testing the SPDY speed from a
client to a SPDY proxy that then connects to a real HTTP site.

It makes no sense to correlate these results with real SPDY web servers
serving real traffic.

------
Sami_Lehtinen
Http vs Spdy: He didn't mention http features like, keep-alive and pipelining
both can make huge difference when sending data over connection having notable
latency

~~~
bluesmoon
pipelining can break sites because of broken proxies that don't understand
pipelining (and there are many). without pipelining, keep-alive only saves you
from extra TCP connections. This is a big improvement, but not enough to go
all the way to what SPDY offers.

------
jamestyrrell
Yeah, this is a pretty old post.. Domain sharding, which is how resource rich
sites enhance parallel loading, doesn't suit SPDY at all.

~~~
bluesmoon
domain sharding has been unnecessary since 2011 when browsers increased the
number of parallel connections they make to a single domain. With these
increased connections, domain sharding might end up hurting performance if all
shards point to the same IP address. This is so because many home wireless
routers and DSL modems start dropping packets if too many SYNs go out to a
single IP without an ACK coming back -- they think the client is mounting a
DoS attack and try to block it.

