16

Just wondering if anyone has had any experience with Google SPDY on Apache? http://code.google.com/p/mod-spdy/

I run a couple of web servers and am interested to know if there have been any issues with the mod_spdy Apache module and if anyone has seen a visible speed increase in SPDY supported browsers?

3
  • There are many protocols supported by SPDY sch as Python, Java, node.js etc. dev.chromium.org/spdy As I am running an Apache webserver mod_spdy is main focus. Commented Jan 27, 2012 at 1:59
  • 3
    @Luke - those aren't protocols.
    – symcbean
    Commented Jan 27, 2012 at 12:07
  • Thanks for the clarification @symcbean. Your input is appreciated. Commented Jan 30, 2012 at 1:13

2 Answers 2

16

I'm one of the developers on mod_spdy. At this stage the module is reasonably stable and fully SPDY/2 compliant (an earlier poster incorrectly claimed that it does not support multiplexing. That is incorrect). That said, it is not as stable as the core Apache modules like mod_ssl. I consider it a "beta" module suitable for use in environments where you can tolerate some issues. There are currently web sites using mod_spdy successfully today.

We are actively working on making the module fully production ready and we plan to release DEB/RPM packages (in addition to supporting build from source) within a few months time.

We will announce the availability of packages and other updates on our discussion forum: https://groups.google.com/group/mod-spdy-discuss Please join the group if you'd like to stay up to date with mod_spdy news. Thanks!

PS: Steve mentions "For example, its implementation of the SPDY protocol is just an svn external reference that pulls in a chunk of the Chromium C++ source tree." and I want to clarify that this is absolutely the right thing for mod_spdy or any other SPDY-compliant C++ component to do. SPDY is still changing rapidly so by leveraging the core SPDY encode/decode logic from Chromium we can stay in sync and up to date as the SPDY protocol changes. IMO it would be a mistake to do it any other way.

RE: SSL you pay a small penalty for SSL, yes, but for all but the simplest web pages the performance benefits of SPDY will make up for the SSL overhead and give your users a secure connection as well.

3
  • Hi Bryan, Thanks for your response. I have been really looking forward to giving SPDY a go on our Apache servers and can't wait for the full production ready release. I hope you make a big song and dance of it when released. Cheers! Commented Feb 8, 2012 at 4:40
  • Hi Bryan, I based the C++ statement on this comment you made back in 2010: goo.gl/QqkPA. Is it no longer the case that you intend to get mod_spdy into mainline Apache? re. Performance; do you have any benchmarks showing the performance improvements with mod_spdy? Commented Feb 9, 2012 at 1:57
  • Steve, you know my history better than I do. :) You are right to draw such a conclusion based on my statement. Things have changed since then, though. In the very early days we debated whether or not to try and implement mod_spdy as a module that could be added to the Apache HTTPD codebase. Since then 2.2 releases have wound down so we are focusing on making a standalone C++ module for 2.2. It may make sense to try to get SPDY support added in Apache trunk, for 2.4 and future versions but it's not on our roadmap at this time. Commented Feb 9, 2012 at 13:24
3

I've played around with mod_spdy on my personal site, purely out of curiosity. The Apache mod_spdy should be considered pre-alpha; it's basically a spike implementation and is nowhere near production quality. For example, its implementation of the SPDY protocol is just an svn external reference that pulls in a chunk of the Chromium C++ source tree. Currently it fails to implement some of important features of SPDY, such as multiplexing. Consequently I've seen negative performance gains using it (largely stemming from the need to force SSL and use FCGI).

It's not clear to me that Apache is the right place to put SPDY anyway; Apache is more of an application container nowadays; the caching layer (Nginx or Varnish) seems more appropriate.

All that said...

The mod_spdy wiki contains some instructions to build against Debian, but I don't recommend their method as it modifies the installed system. Instead I'd recommend building a fresh Apache/SSL install under /opt and run it from there; this gives you an easy rollback option. The rough steps to do this are:

  • Patch OpenSSL with the NPN implementation and install
  • Build Apache against this SSL implementation, enabling the hybrid engine and any mods you need
  • If you need PHP you'll need to build mod_fcgid against Apache
  • Port your existing site config to this new Apache install and test
  • Build and install mod_spdy; this requires Google's depot_tools
  • Configure the non-SSL site to push an "Alternate-Protocol" header (with mod_headers)
  • Disable your existing Apache and setup init scripts for the SPDY version
  • Observe no performance improvement, and a possibly unstable site :)
2
  • Thanks @steve-smith! That is exactly the kind of answer I was looking for. Commented Feb 1, 2012 at 4:56
  • @steve-smith Does spdy has been updated since you made your opinion ? Because your comment kind of makes me unconfortable with the idea of testing spdy on production environment.
    – Tristan
    Commented Jun 11, 2012 at 13:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .