11 ms·

Explain “Event-Driven” Web Servers to Your Grandma

88 points by daverecycles 16y ago

Jinyoung 16y ago
Hmm, perhaps a closer analogy: Traditional Web Server: The pizza shop receives a call for the initial order and starts the pie. Then the customer calls back periodically to check if the pie is done because the pizza shop cannot call back or deliver.
- sabat 16y ago
  Much better. Calling the customer back? That would be magic.
- sausagefeet 16y ago
  No I don't think so. He is talking about a single request here, you seem to be talking about a session.
- chwahoo 16y ago
  The commenter (on the linked blog) who said that the pizza shop has a small number of call-takers that put calls on hold until they are ready to service them makes a better analogy.
- mnutt 16y ago
  The best pizza analogy I could come up with is: In a traditional web server, the person making pizzas only makes one at a time and can't do anything else until that pizza is done and delivered. In an evented model, each pizza maker makes many pizzas at once, and just watches for events (the oven timer goes off) and acts on them. (takes the pizza out) Sometimes if a task is taking him too long, he'll ask an assistant to work on it so that he can get back to making pies.
giberson 16y ago
Grandma, "Event-Driven" is just a fancy word for magic. Don't worry about it.
- Jinyoung 16y ago
  Why are people upvoting this comment? not fully implemented and readily available != magic.
  - rbranson 16y ago
    Not fully implemented? I'm pretty sure all of the billions of requests that hit nginx, varnish, haproxy, and Zeus would disagree with you. What about all those massive sites using memcached on the backend? You know -- Facebook, Twitter, Digg, Craigslist, YouTube?
bartl 16y ago
Explain "web server" to your grandma. Oopsie.
- mishmash 16y ago
  > Explain "web server" to your grandma. Oopsie. It's like a waiter at a restaurant- you tell it what you want and a few moments later, the waiter (or server) returns what you've ordered. Good?
  - gloob 16y ago
    In fairness, that also describes FTP, POP3, and DNS. Edit: and LDAP, and Redis, and medical PACS datastores, and RDBMS in all their multifaceted splendour... a freakish amount of programming boils down to CRUD. Edit 2: and Gopher. I feel a little sad for forgetting about Gopher.
  - noblethrasher 16y ago
    The waiter is the user's agent, the kitchen is the server. Each food preparer in the kitchen is a thread/process. The waiter takes the customer's order and then waits for the food to be prepared before returning with the dish. Asking the the waiter to ask the chef whether or not the fish is fresh is like making a head request.
    - mishmash 16y ago
      Your metaphor is clearly better; grandma performing HEAD requests on fish (a URI) is priceless. However, if granny were in a hurry, she may ask the waiter "Will my order be up soon?" to which the waiter would, after checking with the kitchen and receiving a 304 Not Modified on the still raw fish resource, he could decide to then 307 to some free breadsticks resource. Of course, after lunch, dear granny will eventually receive a 402. Let's hope she has money today, or she may end up 401'ed and have to start washing dishes.
deleted 16y ago
[deleted]
- Jinyoung 16y ago
  I agree. Maybe i'm not on the same page as the article author on what he meant by "event driven" but if he's talking about websockets/comety web servers, then as I mentioned in a comment below, the difference is that in a traditional web server the customer has to keep calling back to know the status of the pizza (polling) versus having the pizzeria deliver or call the customer back for pickup (server push). Fewer communiques overall.
  - sausagefeet 16y ago
    He's talking about handling a single request.
- famousactress 16y ago
  Yeah, maybe putting customers on hold is a better analogy. At which point the limit becomes the phone system's number of maximum customers holding.
vyrotek 16y ago
I feel that this analogy seems to overlook the work that goes into having a 'customer' being available for, listening and receiving the call back.
amalcon 16y ago
"Event-driven" architecture doesn't imply a fundamentally different way of handling requests than thread-based. The only difference is that in an event-driven architecture, the scheduling is handled in the userspace code. In a thread-based architecture, it's done in the kernel. The advantage of doing it in the userspace code is that it can be done in a simpler, more specialized way. The hardware is doing fundamentally the same thing either way, but in the threaded model, it's also doing a lot of other stuff that you probably don't care about. So, to explain it to my grandma: It's just a simpler way to think about it. There isn't really a big difference.
- jerf 16y ago
  "The advantage of doing it in the userspace code is that it can be done in a simpler, more specialized way." No, the advantage of doing it in userspace code is that you can paper over the deficiencies of the layers under the one you are working in with significant manual effort. Node.js introduced the concurrency problems when it selected Javascript as one of the layers, it doesn't get much credit in my mind for then solving them at great effort and with horrible damage done to the resulting program structures. The problems Node.js solves are not fundamental to programming, they are fundamental to Javascript. Pick something like Erlang and the problem never exists in the first place. You don't have to paper over the deficiencies in the lower levels, because the levels below the code you're writing aren't deficient for concurrency in the first place. I should point out that in general this is not necessarily a bad thing; alas, there's always some way your lower layers are deficient, and it's far worse when they make it impossible to paper over the problem. Still, you will never end up with simpler code. More specialized, oh my yes, but certainly not simpler. And the wisdom of picking a layer that is fundamentally deficient for your core target problem then papering over it seems pretty limited to me.
  - sedachv 16y ago
    This is what makes me want to work on operating systems, and in particular exokernel operating systems. There's no reason why OS threads should be expensive, other than hugepages.
  - 16y ago
newhouseb 16y ago
Oh hey, I came up with the exact same analogy about 6 months ago in explaining Tornado and epoll on quora with a bit more technical detail, just replace pizza with pies: http://www.quora.com/Can-someone-explain-poll-epoll-in-Laymans-terms-How-is-Tornado-taking-advantage-of-this-technology/answer/Ben-Newhouse http://www.quora.com/Can-someone-explain-poll-epoll-in-Layma...
kqueue 16y ago
event driven development should be avoided whenever possible. coroutines exist for a reason. Writing event-driven applications is very prone to errors and invalid(impossible) states.
sophacles 16y ago
What a terrible analogy. I mean, there is a pizza-shop or other food service analogy in there, I've made it plenty of times. The problem is that when you make the phone call = request in the analogy, you make the phone connection analogous to the socket. At least have the operator put the caller on hold! Of course then Grandma, not being an idiot, will say "why not just have driver bring the pizza and not have the phone all tied up to begin with?" and she is absolutely correct. It is better to just set up a scenario where you have waiters, and customers show up a the shop, and in blocking your waiter doubles as the cook, so you need one waiter per meal... and so on. This analogy passes a slightly closer examination.
jlew 16y ago
While a great attempt at an analogy, I don't think that it really helps things. I've never misunderstood THAT part of event-based asynchronicity (is that even a word?) The part that is confusing to me is HOW it works and eventually to the point of WHY and/or HOW it is supposedly better than traditional threading (other than cleaner-looking code). I've never seen a good explanation in non-OS programmer terms. To me, it seems that no matter how you take the "messages" to do work, that work still has to be done. It surely doesn't magically use less resources because you told the OS that it could just call you back when it is done, as opposed to you having to hang around? Something has to be hanging around on one side or the other, and the "call back" takes resources as well, surely? It seems that you are just trading tit for tat. Maybe the reason is to not utilize some specific resource in the meantime?
contextfree 16y ago
No! I refuse to explain event-driven web servers to my grandma. You can't make me! I am a free man!
jasonkester 16y ago
Terrible analogy, especially when there exists a better one within the food service industry. How about rewriting that article from the perspective of a coffee shop? We've all been to the neighborhood coffee place where the girl will take your order, turn around and make your entire drink, hand it to you and ask for payment. We've all stood in that line. We've also all been to Starbucks, where the girl takes your order, writes it on a cup, takes your money, then moves on to the next customer. And by the time you walk to the other end of the counter the guy in front of you already has coffee in his hand. It still doesn't fit web servers exactly, but at least it fits the real world.
sambeau 16y ago
What is being described here is blocking and non-blocking IO. The analogy is pretty good. However, the pizza company can probably still only cook 256 pizzas at the same time (due to running out of pan-handles).

88 points by daverecycles 16y ago

Hmm, perhaps a closer analogy: Traditional Web Server: The pizza shop receives a call for the initial order and starts the pie. Then the customer calls back periodically to check if the pie is done because the pizza shop cannot call back or deliver.

sabat 16y ago
Much better. Calling the customer back? That would be magic.
sausagefeet 16y ago
No I don't think so. He is talking about a single request here, you seem to be talking about a session.
chwahoo 16y ago
The commenter (on the linked blog) who said that the pizza shop has a small number of call-takers that put calls on hold until they are ready to service them makes a better analogy.
mnutt 16y ago
The best pizza analogy I could come up with is: In a traditional web server, the person making pizzas only makes one at a time and can't do anything else until that pizza is done and delivered. In an evented model, each pizza maker makes many pizzas at once, and just watches for events (the oven timer goes off) and acts on them. (takes the pizza out) Sometimes if a task is taking him too long, he'll ask an assistant to work on it so that he can get back to making pies.

giberson 16y ago

Grandma, "Event-Driven" is just a fancy word for magic. Don't worry about it.

Jinyoung 16y ago
Why are people upvoting this comment? not fully implemented and readily available != magic.
- rbranson 16y ago
  Not fully implemented? I'm pretty sure all of the billions of requests that hit nginx, varnish, haproxy, and Zeus would disagree with you. What about all those massive sites using memcached on the backend? You know -- Facebook, Twitter, Digg, Craigslist, YouTube?

bartl 16y ago

Explain "web server" to your grandma. Oopsie.

mishmash 16y ago
> Explain "web server" to your grandma. Oopsie. It's like a waiter at a restaurant- you tell it what you want and a few moments later, the waiter (or server) returns what you've ordered. Good?
- gloob 16y ago
  In fairness, that also describes FTP, POP3, and DNS. Edit: and LDAP, and Redis, and medical PACS datastores, and RDBMS in all their multifaceted splendour... a freakish amount of programming boils down to CRUD. Edit 2: and Gopher. I feel a little sad for forgetting about Gopher.
- noblethrasher 16y ago
  The waiter is the user's agent, the kitchen is the server. Each food preparer in the kitchen is a thread/process. The waiter takes the customer's order and then waits for the food to be prepared before returning with the dish. Asking the the waiter to ask the chef whether or not the fish is fresh is like making a head request.
  - mishmash 16y ago
    Your metaphor is clearly better; grandma performing HEAD requests on fish (a URI) is priceless. However, if granny were in a hurry, she may ask the waiter "Will my order be up soon?" to which the waiter would, after checking with the kitchen and receiving a 304 Not Modified on the still raw fish resource, he could decide to then 307 to some free breadsticks resource. Of course, after lunch, dear granny will eventually receive a 402. Let's hope she has money today, or she may end up 401'ed and have to start washing dishes.

deleted 16y ago

[deleted]

Jinyoung 16y ago
I agree. Maybe i'm not on the same page as the article author on what he meant by "event driven" but if he's talking about websockets/comety web servers, then as I mentioned in a comment below, the difference is that in a traditional web server the customer has to keep calling back to know the status of the pizza (polling) versus having the pizzeria deliver or call the customer back for pickup (server push). Fewer communiques overall.
- sausagefeet 16y ago
  He's talking about handling a single request.
famousactress 16y ago
Yeah, maybe putting customers on hold is a better analogy. At which point the limit becomes the phone system's number of maximum customers holding.

vyrotek 16y ago

I feel that this analogy seems to overlook the work that goes into having a 'customer' being available for, listening and receiving the call back.

amalcon 16y ago

"Event-driven" architecture doesn't imply a fundamentally different way of handling requests than thread-based. The only difference is that in an event-driven architecture, the scheduling is handled in the userspace code. In a thread-based architecture, it's done in the kernel. The advantage of doing it in the userspace code is that it can be done in a simpler, more specialized way. The hardware is doing fundamentally the same thing either way, but in the threaded model, it's also doing a lot of other stuff that you probably don't care about. So, to explain it to my grandma: It's just a simpler way to think about it. There isn't really a big difference.

jerf 16y ago
"The advantage of doing it in the userspace code is that it can be done in a simpler, more specialized way." No, the advantage of doing it in userspace code is that you can paper over the deficiencies of the layers under the one you are working in with significant manual effort. Node.js introduced the concurrency problems when it selected Javascript as one of the layers, it doesn't get much credit in my mind for then solving them at great effort and with horrible damage done to the resulting program structures. The problems Node.js solves are not fundamental to programming, they are fundamental to Javascript. Pick something like Erlang and the problem never exists in the first place. You don't have to paper over the deficiencies in the lower levels, because the levels below the code you're writing aren't deficient for concurrency in the first place. I should point out that in general this is not necessarily a bad thing; alas, there's always some way your lower layers are deficient, and it's far worse when they make it impossible to paper over the problem. Still, you will never end up with simpler code. More specialized, oh my yes, but certainly not simpler. And the wisdom of picking a layer that is fundamentally deficient for your core target problem then papering over it seems pretty limited to me.
- sedachv 16y ago
  This is what makes me want to work on operating systems, and in particular exokernel operating systems. There's no reason why OS threads should be expensive, other than hugepages.
- 16y ago

newhouseb 16y ago

Oh hey, I came up with the exact same analogy about 6 months ago in explaining Tornado and epoll on quora with a bit more technical detail, just replace pizza with pies: http://www.quora.com/Can-someone-explain-poll-epoll-in-Laymans-terms-How-is-Tornado-taking-advantage-of-this-technology/answer/Ben-Newhouse http://www.quora.com/Can-someone-explain-poll-epoll-in-Layma...

kqueue 16y ago

event driven development should be avoided whenever possible. coroutines exist for a reason. Writing event-driven applications is very prone to errors and invalid(impossible) states.

sophacles 16y ago

What a terrible analogy. I mean, there is a pizza-shop or other food service analogy in there, I've made it plenty of times. The problem is that when you make the phone call = request in the analogy, you make the phone connection analogous to the socket. At least have the operator put the caller on hold! Of course then Grandma, not being an idiot, will say "why not just have driver bring the pizza and not have the phone all tied up to begin with?" and she is absolutely correct. It is better to just set up a scenario where you have waiters, and customers show up a the shop, and in blocking your waiter doubles as the cook, so you need one waiter per meal... and so on. This analogy passes a slightly closer examination.

jlew 16y ago

While a great attempt at an analogy, I don't think that it really helps things. I've never misunderstood THAT part of event-based asynchronicity (is that even a word?) The part that is confusing to me is HOW it works and eventually to the point of WHY and/or HOW it is supposedly better than traditional threading (other than cleaner-looking code). I've never seen a good explanation in non-OS programmer terms. To me, it seems that no matter how you take the "messages" to do work, that work still has to be done. It surely doesn't magically use less resources because you told the OS that it could just call you back when it is done, as opposed to you having to hang around? Something has to be hanging around on one side or the other, and the "call back" takes resources as well, surely? It seems that you are just trading tit for tat. Maybe the reason is to not utilize some specific resource in the meantime?

contextfree 16y ago

No! I refuse to explain event-driven web servers to my grandma. You can't make me! I am a free man!

jasonkester 16y ago

Terrible analogy, especially when there exists a better one within the food service industry. How about rewriting that article from the perspective of a coffee shop? We've all been to the neighborhood coffee place where the girl will take your order, turn around and make your entire drink, hand it to you and ask for payment. We've all stood in that line. We've also all been to Starbucks, where the girl takes your order, writes it on a cup, takes your money, then moves on to the next customer. And by the time you walk to the other end of the counter the guy in front of you already has coffee in his hand. It still doesn't fit web servers exactly, but at least it fits the real world.

sambeau 16y ago

What is being described here is blocking and non-blocking IO. The analogy is pretty good. However, the pizza company can probably still only cook 256 pizzas at the same time (due to running out of pan-handles).