> In a synchronous language, you HAVE TO go to one shard, then another, then another, and the time is 10x longer.
Have you ever heard of threads?
Have you ever heard of threads?
When NGiNX launched, it was the evented web server in a sea of threaded servers. Guess which paradigm won.
Meteor seems to think threads are the way to go (Fibers)
PHP does preforking first of all. You have about 30 "threads" sitting around, able to handle 30 clients. This is STILL not the same as evented programming, which lets you send out these requests and wait.
Speaking of -- have you ever heard of evented i/o?
Let me put it this way ... threads and workers are good for handling incoming requests (one worker per request). But for outgoing requests, it's nice to have evented i/o!
https://github.com/jruby/jruby/wiki/Concurrency-in-jruby
> Speaking of -- have you ever heard of evented i/o?
Yes, I wrote a Ruby wrapper to libev before Ry wrote Node, and this coroutine abstraction to get rid of the async gunk, but Ry left that part out:
Linux has an O(1) scheduler.
Threads do have a cost in terms of virtual memory, but on 64-bit architectures, this is a non-issue.
Optimizing for "C10K" (which, btw, was a big number in 1999, not today) by using an event loop will actually harm latency and performance in the case that you are dealing with a small number of highly active connections. Believe it or not the kernel can do just as good (or better) a job of scheduling than Node's event loop.