5 ms·
Add SPDY support to your Apache server with mod_spdy
- maratd 14y agoWhat? Why not Apache 2.4? That's the current stable version.
- nfm 14y agoCan't wait for SPDY to be implemented for nginx. There's been discussion about it several months ago, but I haven't heard anything since. Does anyone who's involved with nginx have more info?
- chc 14y agoAccording to the nginx Twitter, they're targeting a May release: http://twitter.com/#!/nginxorg/status/192301063934705665 http://twitter.com/#!/nginxorg/status/192301063934705665
- piotrSikora 14y agoThey're targeting _May_ release.
- chc 14y agoOK, I removed the joke about software schedules for the sake of not confusing anyone (especially since I realized this thread will probably rank for [nginx spdy] in like two minutes).
- wmf 14y agoThat architecture sounds like a DoS nightmare. Now you can run out of Apache processes much faster! I wonder if mod_spdy has any built-in mitigation for this.
- saurik 14y agoPlease stop using mpm_prefork... it is 2012: mpm_event just officially went stable (although it has worked fine for years) and mpm_worker has been the correct option for most of Apache 2.x. (edit: I make this point because I handle thousands of concurrent requests with a small handful of processes; I run out of memory way before I run of processes.)
- jdub 14y agoIt is 2012, and anyone using PHP with Apache 2.2 will be using mpm_prefork. Much as the popularity of nginx deployments with PHP/fastcgi has grown, I suspect we'll see more mod_php-less Apache deployments as Apache 2.4 grows in popularity.
- saurik 14y agoAFAIK, mod_php has been compatible with mpm_worker for many years now... it is only that there are a few PHP extensions that are incompatible, and people don't want to spend the time documenting which ones those are, so their default recommendation has always been "use mpm_prefork": if you actually care about your deployment you can just figure out whether your extensions are compatible.
- grecy 14y agoFrom the comments on that article, it looks like Google will only implement SPDY for HTTPS, because Google believe that's the future of all HTTP requests. I'm not cool with that. I feel like a ton of HTTP requests are for very simple html pages that don't require any kind of login/security and the overhead of HTTPS is of no benefit.
- nickpresta 14y agoIf the page is just 'simple html', why does the overhead matter? I would imagine that the overhead of fetching data from a database, talking to the network, etc, would outweigh the cost of doing an SSL handshake if you bundle your resources correctly.
- ComputerGuru 14y agoYou're contradicting yourself here. If it's plain HTML, there's none of the database/intranet/etc going on and so every bit of overhead is noticeable... which is the point the GP was trying to make. Not that I share that opinion. I think the whole world needs to move on SSL, even though it's kinda broken in the current method where a select few companies make a crazy killing selling their SSL certs (although there are cheap alternatives).
- nickpresta 14y agoMy two points were unrelated. If it's a simple HTML site - who cares? A simple HTML site with < 100KB of content and < 15 resources to fetch isn't a bit deal anyways. Two or three seconds to a user on a mobile device isn't unreasonable. If the site is more complex, the SSL handshake most likely isn't your bottleneck. I found this[1] to be an interesting read. [1]: http://www.semicomplete.com/blog/geekery/ssl-latency.html http://www.semicomplete.com/blog/geekery/ssl-latency.html
- brandon 14y agoI'm completely cool with it. Modern equipment can handle plenty of SSL traffic, and SSL-by-default will protect me (and you) from lazy developers. The real question is whether or not this will proliferate and to what extent.
- vgnet 14y agoA bit OT, but has anyone noticed that Twitter seems to have stopped using SPDY? Any information on that?
- cagenut 14y agoIts not clear from the post, are they implementing their own mpm? as in mod_spdy takes the place of mod_prefork/worker/event?
- SeoxyS 14y agoI wonder how SPDY would work in a load-balanced environment. - Should the load balancer use implement SPDY externally and use HTTP internally? - Should internal request be 100% SPDY-only and the load balancer implement both?
- whalesalad 14y agoI think currently the most convenient thing is to use HTTP internally and have something on the front end that does SPDY between end-user and server. Seems like SPDY would be beneficial as a replacement for HTTP everywhere though, because the payload for each request is smaller. However, SPDY seems to be optimized for the longer, higher latency, and slower connection between user and server rather than the faster internal connection between load balancers and servers. Finally, all SPDY communication is encrypted via TLS, so that process might add to a slowdown between internal systems. Guess we'll need to benchmark it and see! Looks like Apache and Jetty are the only supporters of this so far. And I'd never us Apache as a direct front-end.
- WALoeIII 14y agoIt doesn't really matter. For simplicity put SPDY on the edge and reverse proxy HTTP to whatever you used to use, this gets you 90% of the way there. In the future, I expect we'll see tools like Mongrel2 take over. SPDY on one end, and some type of messaging on the other side. This will become more desirable with technologies like web-sockets that will stream data back. HTTP is simple, but hardly optimized for speed, even on a LAN. Thrift, Protobuffs, MessagePack, even Erlang's Binary Protocol (i.e. BERT) are all better fits for the internal RPC protocol
- zobzu 14y ago" make BUILDTYPE=Release" cool but there's no makefile in their source.
- deleted 14y ago[deleted]
- chrisbroadfoot 14y agoThat doesn't look right to me. Here's how it looks for me: http://www.dropmocks.com/mBiQ4E http://www.dropmocks.com/mBiQ4E