5 ms·

Can you provide us with an idea of how much this improved performance or how many more requests it allowed you to handle? Were there time or cost savings compar

by jot 14y ago

Can you provide us with an idea of how much this improved performance or how many more requests it allowed you to handle? Were there time or cost savings compared to alternative approaches?

transmit101 14y ago
There's no single self-contained solution in the post really, it's more an illustration of a number of useful things that Lua can be used for. I might try to put another post together at some stage though. 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.
- themgt 14y ago
  Yeah, we're using this to map hosts->upstream servers/redirects in a redis DB, and then there's no need for managing vhost files to add/remove/scale sites (or adding/swapping nginx servers). Writing code instead of config files is very powerful
taligent 14y ago
It is non-blocking and executed within Nginx itself so it is supposed to be very fast. The Lua work has been done by Chinese engineers from Taobao and Weibo which obviously get a huge amount of traffic.
- transmit101 14y ago
  I didn't know about the Weibo connection. 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.

by jot 14y ago

Can you provide us with an idea of how much this improved performance or how many more requests it allowed you to handle? Were there time or cost savings compared to alternative approaches?

transmit101 14y ago

There's no single self-contained solution in the post really, it's more an illustration of a number of useful things that Lua can be used for. I might try to put another post together at some stage though. 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.

themgt 14y ago
Yeah, we're using this to map hosts->upstream servers/redirects in a redis DB, and then there's no need for managing vhost files to add/remove/scale sites (or adding/swapping nginx servers). Writing code instead of config files is very powerful

taligent 14y ago

It is non-blocking and executed within Nginx itself so it is supposed to be very fast. The Lua work has been done by Chinese engineers from Taobao and Weibo which obviously get a huge amount of traffic.

transmit101 14y ago
I didn't know about the Weibo connection. 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.