If you are one of them who don’t “get” why eventing scales, that’s ok.
When I first saw evented programming, I din’t get it too. I’ll try to
this explain as simple as I can. But first read this line: “Evented
servers usually share one thread for all requests unlike threaded
servers that spawn one thread per request”. Read that last line one more
time. But what’s the big deal with this? Nothing. Now forget that and
read on.
You get a mail from a leading movie theater in your city regarding a business opportunity:
Hi,
We at AA-Theater want get out of the damn-internet and sell all movie tickets at the counter. We want to outsource the business of selling offline tickets to you. To test how this would work we want to start with one show. The Evening show. Since the evening show is the most watched of all shows, you can assume unlimited people and unlimited tickets(as much as you can sell). The only problem is, you can sell tickets only between 5:30 PM to 6:00 PM(Government rules). You can have as many counters as you want. You take a 50% cut in all the tickets you sell.
President, The AA-Theater
p.s: Customers will be mostly ladies
50% cut and unlimited tickets to sell?! Put that in perspective. If you manage to sell only 10 tickets at $10 in that 30 minutes, you make $50. But if you manage to sell a 1000 tickets you make $5000. Awesome!. Plus, “this is non-technology” you think. No coding. No Servers. No database. No scaling. No nightmares. No running behind investors. You only have one easy-to-define goal. You must sell as much as possible in that 30-minute time frame.
Next day you start your work and it goes like this:
You made one interesting observation on your first day of selling. The time it takes for a lady to think and answer the simple question “How many tickets do you want?” is directly proportional to their weight. Like that fat lady wearing a brown blouse, she took almost 5 minutes to answer. And that pretty thin girl in pink, you din’t even had to ask. That’s quite an insight.
Before we see how put this insight to use, lets try to correlate. Back in the time when you did server coding, your server received requests. Many requests. Some requests took a lot of time to complete (fat-lady-requests) like the report which needed to execute a 100 sql queries. And some requests were small(thin-lady-requests). Your job was scale the server so it serves the maximum no of requests within a given time. Exactly like selling the max no of tickets within 30 minutes “Similarity” you think “Just when I thought those pesky coding days we over for good” .
The next day something goes terribly wrong. Your first customer is a really-fat lady who takes 30 minutes just thinking how many tickets to buy and finally says “Hmm. forget it, I left my purse at home”. Nightmare! Even though there were like a 1000 more people behind her in the queue, you managed to sell Zero tickets.
“I’ve got to do something”, you declare, “But what?”. You correlate back
to your coding days and it strikes you. All this time You’ve just been
using one thread(One counter) and queueing all requests(people) into
that one queue. That sucks. Your mind starts racing. “I need a counter
pool” and evenly distribute the people among all these counters.
It’s day 3 and you start with a smile. Now you have like 10 counters. Your customers queue up evenly. This is fine, you think, because, even if a fat lady causes a bottle neck on one queue, on the other queues, you can still sell. Hm.. But something still feels wrong. You know this feeling is related to something your algorithm professor told you. What was it.. Order of n. Worst case. “I’ve got to get my mind off the coding” you decide. and move on. On day 3 you sell a record no. of tickets.
Then, on day 4, the nightmare repeats. The first set of people to enter your counters that day were a group 10 fat ladies. You watch bewildered as these 10 ladies distribute and take each of the counters, spoil the 30 minutes and then leave of with just 10 tickets total.
“This is disaster”, you think, “Tomorrow I could have a 100 counters but if the ‘first’ 100 people who enter my counters took a long time to buy, I am still doomed”
You think hard again, and it strikes you. You come up with a simple but
very effective solution. In fact the solution is so simple that it
doesn’t event need these 10 counters.
On day 5 when customers come in to buy tickets, they find a board that you have hung up near the counter. And it says
Here's the deal. Stand in the queue. When you are at the counter, we ask you 'How many tickets you want to buy?'. If you can't answer that immediately, step out of the queue, think about it and join the queue back.
Think about how will this solve your problems. It doesn’t matter who comes first. Say A fat lady comes in first. You ask “how many tickets?”, she steps out of the queue to think, and while she is thinking, you sell more tickets to other ladies and when the fat lady has thought about it she joins back queue.
This is exactly what evented architectures lets you do. Instead of spawning one thread for every request they run all requests on one thread. But, every time the program execution stops to think(when doing an IO), it is pushed out of the queue. When it has the result, it can come back.
Congratulations. You did evented ticket distribution. How cool is that? Now you can hope to become a millionaire without ever applying to Y-combinator :)
s.1: The totally-worst case remains same with the two strategies. For eg., if all your customers were fat ladies you could still end up not selling anything. But with the first strategy, if the “first n customers” were fat ladies you are doomed. With the latter that is not the case.
s.2: Think about how you can still have multiple counters along with this strategy
s.3: If you are a fat lady and you are hurt with this post. Good. Try and get slim :)