For us our main goal is to prevent the majority of requests from even reaching the Rails stack. We've done this by introducing full page caching across the site, for both logged in and logged out users. This means that only a small percentage of requests at peak times need to touch Rails or any database at all - everything is served by Nginx.
This hasn't been without its challenges. The last section of this post might give a clue as to how we've solved the most difficult ones. I will think about a post tackling this whole subject but I need to think about how to get it across, it's not easy.
It is a very fast module, and non-blocking, but just as importantly it provides the flexibility to avoid sending requests from Nginx to slow backend servers (Ruby, Python, whatever) at all. In real-life situations, this is the most important bit.
As I said in another thread, we've done some good work to tie this in with our Rails app. We now page cache almost every important request, even for logged in users. This means Rails and our databases are protected from most spikes of traffic. I would like to write a post describing this in more detail, I need to think how to get it across though.
Once you are writing interpreted code which reads request data and interacts with Redis you are not that far from what a normal Ruby or Python web app does anyway.
Also, Lua is a very nice language, easy to learn (there is not much of it), and most of the functionality exposed is simply the built in functionality of nginx (async http), plus some libraries, so having the libraries that come with other languages is not that useful as you can't use anything blocking (like with Node) inside Nginx.
Embedding Python in a web server is quite doable and has nothing to do with having libraries available.
I'm really not seeing why everyone should switch to Lua for these tasks. That is quite different from saying that people who like Lua shouldn't use it.
1. Lua is very easy to embed into C code. Python and Ruby, not even in the same ball park ... 2. This nginx+lua config is often implemented using LuaJIT. Luajit is the fastest dynamic language. it's speed is very close to Java's in many cases. So, very little performance penalty..
Or has it been decided (as if a priori) that Lua is the only workable solution?
By keeping everything non-blocking and inside the Nginx event loop, and cutting the upstream out entirely, we are making a massive saving on each request. This definitely outweighs a small performance penalty incurred for using LuaJIT.
It is possible that Ruby is impracticably slow in itself, I guess.
Keeping things non-blocking and inside the Nginx event loop doesn't specifically mean you have to use Lua, does it?
For what you're trying to do, I feel like implementing your reverse proxy in Go may prove to be less prone to errors. Go has ReverseProxy stuff already built in: http://golang.org/pkg/net/http/httputil/#ReverseProxy
Go already has a pretty strong following doing near exactly what you are doing here with Nginx + Lua. But that would require learning a new language and screwing with infrastructure, which always is a giant pain.
In comparison, Go is a pretty much unknown quantity.
I'm curious as to what problems you think that this might lead to that aren't just as likely or more likely with a Go based implementation.
I don't think there are any problems, or that it is error prone. Most people are learning a new language with Lua, so take your choice.
As another commenter says, there is a large Nginx community and we have a lot of investment in Nginx already. But for somebody starting from scratch it may be worth considering.
I might have misunderstood that first bit though, since it looks like you do redirect anyway.
