Show HN: During the last week, I built a SPDY server.
github.com
github.com
1) your backend servers should use their hardware for actually running the web application, not for encrypting responses.
2) usually, your backend servers only serve the dynamically generated content. SPDY's biggest advantage is that it would allow to handle multiple requests in one connection, but this really shines for static assets (images, stylesheets) which in turn are rarely served by the backend.
3) Even if you want to do SPDY on the backend, your frontend proxies still have to support it, because that's what the clients are talking to.
So as it stands now, having SPDY on the backend server (or even in your application like this project here) doesn't really give you any of SPDY's advantages unless you begin serving all of your site directly from your application servers, which we learned over the last years, just doesn't scale as well.
"[The results] show the power that lies in the simple addition of a SPDY server to an existing nginx/Thin configuration (and probably also Unicorn/nginx.)"
I am totally for the separation of front- and backend.
Would this technology be beneficial to Hacker News? Is the site currently hosted on a SPDY-compatible server?
Edit: nope, that's not it. Using the fastest UK machine with clean net available to me, tcpdump never shows more than 1 unacked packet on the wire at any time, gzip is turned off, and keepalive is turned off. Gzipping the 24k home page drops it to 4.3k.
None of this really accounts for the crazy jitter we see in Europe while rendering the main table.
For me:
The top half of the page draws instantly in Chrome, then the bottom half.
In firefox, the page draws incrementally, line by line.
In IE9, the whole page draws pretty much instantly, much quicker than FF or Chrome for me.
Headers are gziped, concurrent request on a single TCP session, everything over ssl and some push capabilities.