Actual snippets of a conversation I recently endured between my husband and our friend.
Also known as "Geek Talk"

The multi-threaded design?

Yeah it is a bad design. Back in the day, it was a great design. … For the developer, the thread per request model is tons simpler. You’d say, “I’m gonna go fetch a file” and it was very sequential.

The big advantage to an event-driven database driver is that what if for this web request you have to query two databases… It lowers your latency, so you can process your request more quickly and make it more scalable.

There’s obviously a cost for every thread you have. But obviously there’s the latency and the time.

But the non-blocking approach is more scalable.

Do you have one disk and you’re constrained by this seek time? Or do you have this array … ?

How much more scalability are you gonna get? We need to throw these application servers out the window.

But the client application developers, who are making the client side of the application, don’t have to…

If you’re talking about a client that’s sending a web request, then yeah, they don’t change anything.

How much performance difference is there doing essentially the same task?

The nice thing is that is should be fairly easy to do comparisions because I just have to write really simple Java applications… It’s like comparing the traditional model with the event-driven model.

I wonder with how many layers there are, is there any constraint with the type of performance you’re getting.

They’re not doing a lot of disk I/O if you’re doing repetitive queries. When the bottleneck disappears, how much performance can be gained? This model can get much more scalable web servers.

They have a web server that’s able to scale about four times better than Apache because it’s using this different approach. It can handle 15,000 web requests and keep the pipe as full as it can. They can fully saturate both gigabit cards.

If I have time, I’m gonna use the Linux-specific calls and build a framework around that.

It might be worthwhile to get an operating system with good support for asynchronous file transfer.

I’d be really interested to see how Oracle works under the hood because it does tons of asynchronous I/O stuff. How can there be 16,000 requests? [What the heck?]

How in the heck is it scheduling everything to fetch some stuff asynchronously and other stuff not asynchronously? It must have a pool that handles it all.

You get signal call back, so it basically gets interrupted.

Put it in the queue to get called.

If you want a whole bunch of different file channels, you can do that.

You’re calling Java from C?

Yeah. Java calls C and then C calls Java back.

“Here’s an early look at what the API is probably going to look like.”

That's interesting.