Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Explain “Event-Driven” Web Servers to Your Grandma

daverecycles.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Explain “Event-Driven” Web Servers to Your Grandma

#12

Post by amalcon »

"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.

Re: Explain “Event-Driven” Web Servers to Your Grandma

#13

Post by jerf »

amalcon wrote: post #12

"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 fundamentall…

"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.

Re: Explain “Event-Driven” Web Servers to Your Grandma

#15

Post by mnutt »

Jinyoung wrote: post #2

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.

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.

Re: Explain “Event-Driven” Web Servers to Your Grandma

#16

Post by rbranson »

Jinyoung wrote: post #11
giberson wrote: post #3

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

Why are people upvoting this comment? not fully implemented and readily available != magic.

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?

Re: Explain “Event-Driven” Web Servers to Your Grandma

#17

Post by sedachv »

jerf wrote: post #13
amalcon wrote: post #12

"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 fundamentall…

"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…

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.

Re: Explain “Event-Driven” Web Servers to Your Grandma

#18

Post by sausagefeet »

Jinyoung wrote: post #10
[deleted] wrote: post #7

[deleted]

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 co…

He's talking about handling a single request.
Post reply on HN