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.
The performance of your SPDY setup will obviously depend on the implementation of the stack and you should know the processing cost vs. a 'regular' HTTP or HTTPS session, but.. Keep in mind that that the primary point of SPDY is to reduce the latency and overhead of rendering a typical webpage (as seen by your visitors), not to optimize your server-side response time.
More specifically: if you want to benchmark SPDY, siege/ab and friends are not representative. All of these tools generate load against a single URI and hammer it. This is a useful tactic to stress test your server, but it is far from testing the benefits of SPDY. To test SPDY, you want a tool (browser, most likely), which will download the page, and request all the subresources on the page, allowing you to reuse the SPDY connection.
We recently ran some benchmarks using Chrome for Android, and you can see the setup here: https://developers.google.com/speed/articles/spdy-for-mobile
Finally. If you do need a command line client to test SPDY, checkout spdylay. It ships with spdycat which will allow you to make curl-like requests against your server. It's not a benchmarking tool, but it'll get you started.
Best Answer
The issue is that Chrome 40.x dropped support for SPDY/3 and only supports SPDY/3.1, but the mod_spdy module for Apache only supports SPDY/3, so basically no SPDY for Chrome users if you use Apache as a web server.
mod_spdy is currently in a bad state where either Google nor Apache is maintaining it after Google donated it to the Asf. Google recently made the statement that they will drop the SPDY support from Chrome in early 2016, but what they forgot to say that they started dropping older versions of SPDY already (including SPDY/3) (I like these partially true statements by the way), so basically if you are on Apache then for your Chrome users you can't provide SPDY short of implementing SPDY/3.1 yourself.
So, how was that for "do no evil"? :-)
See details: https://groups.google.com/forum/#!topic/mod-spdy-discuss/FPEj0zG5I0Y and https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20Stars
One option you might consider is switching to Nginx and using the SPDY/3.1 implementation over there.