I want to understand basics of Event Driven web server, I know one of them is Tornado, but any other information is much appreciated.
Thanks
There's a nice analogy of this described here:
http://daverecycles.tumblr.com/post/3104767110/explain-event-driven-web-servers-to-your-grandma
Relevant text from the above link:
Explain “Event-Driven” Web Servers to Your Grandma You’ve heard the term event-driven, event-based, or evented when it comes to web servers. Node.js is based on evented I/O. nginx is an asynchronous event-driven web server.
But what does the term mean? Here’s an easy way to think about it.
Let’s think of a web server as a pizza shop that needs to take orders over the phone (requests for web pages).
Traditional Web Server
The pizza shop hires operators (processes/threads) to take orders over the phone. Each operator has one phone line. After the operator is done taking the order, the operator keeps the customer on the line until the pizza (response web page) is done baking and then tells them it’s ready to pick up.
So the pizza shop needs to hire as many operators as the number of pizzas that may be baked at once in order to serve all customers who call in.
Event-Driven Web Server
The pizza shop only hires one operator, but has trained the operator to hang up after taking the order, and call the customer back when the pizza is ready to be picked up.
Now one operator can serve many customers.
A web server needs to handle concurrent connections. There are many ways to do this, some of them are:
At the end, the distinction ends up being in how you store each connection state (explicitly in a context structure, implicitly in the stack, implicitly in a continuation, ...) and how you schedule between connections (let the OS scheduler do it, let the OS polling primitives do it, ...).
Event-driven manner aims at resolving the C10K Problem. It turns the traditional 'push model' into a 'pull model' to create a non-blocking evented I/O. Simply put, the event-driven architecture avoid spawning additional threads and thread context switching overheads, and usually ends up with better performance and less resource consumption.
Some overview from a rails developer, also includes analogy: http://odysseyonrails.com/articles/8