7 ms·

Show HN: During the last week, I built a SPDY server.

85 points by sokrates 15y ago

ndrarmst 15y ago
Great work. I'm not as up-to-date on SPDY servers as I should be, but this seems to be one of the few suited for non-trivial use cases.
WALoeIII 15y ago
This is great! Nice work!
MikeCapone 15y ago
Disclaimer: I am not a programmer or web guy. Would this technology be beneficial to Hacker News? Is the site currently hosted on a SPDY-compatible server?
- i386 15y ago
  Its only for Rack based apps (Ruby) and this website is written in pg's own lisp-like language. So, no :)
  - MikeCapone 15y ago
    Maybe I'm confused; I thought SPDY was a HTTP replacement written by Google: http://en.wikipedia.org/wiki/SPDY http://en.wikipedia.org/wiki/SPDY
    - SpikeGronim 15y ago
      Yes, SPDY is a cross-platform protocol. This submission is a Ruby implementation of a SPDY server for Rack applications like Ruby on Rails. The news.ycombinator.com server is written in the arc language. SPDY is awesome.
      - MikeCapone 15y ago
        Ok. It's my fault for not being clear in my original message. I wasn't talking about the linked SPDY implementation but about SPDY in general. Sorry, I should have marked it as OT.
        i386 15y ago
        All good - we are all here to share knowledge :-)
- stingraycharles 15y ago
  No, HN is currently using the regular HTTP protocol. In my opinion, the costs of implementing SPDY support, at the moment, outweigh the benefits of that support.
- wmf 15y ago
  SPDY benefits pages that make many requests (lots of CSS, JS, images, etc.); HN doesn't have any of that so no.
  - nextparadigms 15y ago
    I don't know why, but I find HN pretty slow for a page that only shows 30 links. Engadget takes about half the time to load. Granted this is with Adblock and WidgetBlock, which I use to block all 3rd party connections besides Disqus, but HN doesn't use any of that anyway, so it's still strange.
    - forgotusername 15y ago
      HN does no output buffering, causing rendering time to often be closer to 5 seconds than 100ms in Europe. This is trivial to fix, but I guess the SFO crowd don't feel the pain so it probably never will. 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.
      - EwanToo 15y ago
        Sat in the UK I don't see anything like a 5 second render time for HN, maybe 1 second at most. 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.
- resnamen 15y ago
  Wouldn't fix all the "unknown or expired links"!
  - dextorious 15y ago
    Well, re: speed and lack of bugs, HN is really not the best showcase for functional languages in web programming...
chetan51 15y ago
Stupid question, but what are the advantages of SPDY? And how should the average hacker use it?
- latch 15y ago
  speed and security. Headers are gziped, concurrent request on a single TCP session, everything over ssl and some push capabilities.
pilif 15y ago
IMHO, SPDY should be implemented on the frontend servers like varnish, HAProxy or nginx. If you do SPDY on the backend server, you cause a lot of additional problems: 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.
- sokrates 15y ago
  The author here. I can understand that it's not clear from the README, but I only chose a Rack implementation for the backend in order to make developing those 'Adapters' easier for others, since Rack is pretty standard in the Ruby world. One of the implemented adapters, Proxy, acts a proxy to another HTTP server. In the performance section: "[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.

85 points by sokrates 15y ago

Great work. I'm not as up-to-date on SPDY servers as I should be, but this seems to be one of the few suited for non-trivial use cases.

WALoeIII 15y ago

This is great! Nice work!

MikeCapone 15y ago

Disclaimer: I am not a programmer or web guy. Would this technology be beneficial to Hacker News? Is the site currently hosted on a SPDY-compatible server?

i386 15y ago
Its only for Rack based apps (Ruby) and this website is written in pg's own lisp-like language. So, no :)
- MikeCapone 15y ago
  Maybe I'm confused; I thought SPDY was a HTTP replacement written by Google: http://en.wikipedia.org/wiki/SPDY http://en.wikipedia.org/wiki/SPDY
  - SpikeGronim 15y ago
    Yes, SPDY is a cross-platform protocol. This submission is a Ruby implementation of a SPDY server for Rack applications like Ruby on Rails. The news.ycombinator.com server is written in the arc language. SPDY is awesome.
    - MikeCapone 15y ago
      Ok. It's my fault for not being clear in my original message. I wasn't talking about the linked SPDY implementation but about SPDY in general. Sorry, I should have marked it as OT.
      - i386 15y ago
        All good - we are all here to share knowledge :-)
stingraycharles 15y ago
No, HN is currently using the regular HTTP protocol. In my opinion, the costs of implementing SPDY support, at the moment, outweigh the benefits of that support.
wmf 15y ago
SPDY benefits pages that make many requests (lots of CSS, JS, images, etc.); HN doesn't have any of that so no.
- nextparadigms 15y ago
  I don't know why, but I find HN pretty slow for a page that only shows 30 links. Engadget takes about half the time to load. Granted this is with Adblock and WidgetBlock, which I use to block all 3rd party connections besides Disqus, but HN doesn't use any of that anyway, so it's still strange.
  - forgotusername 15y ago
    HN does no output buffering, causing rendering time to often be closer to 5 seconds than 100ms in Europe. This is trivial to fix, but I guess the SFO crowd don't feel the pain so it probably never will. 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.
    - EwanToo 15y ago
      Sat in the UK I don't see anything like a 5 second render time for HN, maybe 1 second at most. 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.
resnamen 15y ago
Wouldn't fix all the "unknown or expired links"!
- dextorious 15y ago
  Well, re: speed and lack of bugs, HN is really not the best showcase for functional languages in web programming...

chetan51 15y ago

Stupid question, but what are the advantages of SPDY? And how should the average hacker use it?

latch 15y ago
speed and security. Headers are gziped, concurrent request on a single TCP session, everything over ssl and some push capabilities.

pilif 15y ago

IMHO, SPDY should be implemented on the frontend servers like varnish, HAProxy or nginx. If you do SPDY on the backend server, you cause a lot of additional problems: 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.

sokrates 15y ago
The author here. I can understand that it's not clear from the README, but I only chose a Rack implementation for the backend in order to make developing those 'Adapters' easier for others, since Rack is pretty standard in the Ruby world. One of the implemented adapters, Proxy, acts a proxy to another HTTP server. In the performance section: "[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.