Re: Performance techniques used in AWS

["R. Tyler Croy" <tyler@linux.com>]

On Mon, 13 Jun 2011 18:28:28 +0200, Pascal Obry wrote:

> Le 13/06/2011 07:48, R. Tyler Croy a écrit :
>> I asked this in #Ada and couldn't find any decent documentation on some
>> of the techniques used in AWS to make it perform as well as it
>> apparently does (at least according to Thomas' silly
>> benchmarks:<http://wiki.ada- dk.org/index.php/AWS_vs_node.js>)
>>
>> Surely beyond simple tasking there's some interesting approaches AWS
>> must be using to make it fast (I don't have the time nor expertise to
>> figure it out on my own)
> 
> Sadly I fear there is no magic. I have never ever tried to build
> something fast in fact and never tried to optimized things a lot. I've
> always been concentrated to provide a simple and sound design. The heart
> of AWS has almost not been changed since it inception. I was the first
> surprised to see it being so fast.
> 
> Note that Dmitriy Anisimkov already reported long time ago very good
> response time.
> 
> I've seen so many applications molested to gain some speed without
> testing properly first... AWS is not in this category.
> 
> The heart of the web server design is quite simple: a single queue for
> the incoming requests. Those requests are dispatched to a free task
> taken from a a poll. That's pretty all there is about it.


What I'm trying to work out in my head is how to build an application (in 
Ada) that can compete[0] effectively with a libev-based program written in 
C. The advantage that libev brings to the table is that this program (in 
C) can very easily handle and respond to tens of thousands of concurrent 
connections.

Unlike AWS or most web servers however, these connections are not HTTP-
based and do not follow the traditional Request->Response->Close pattern 
of most of the HTTP world, but rather sockets are held open for minutes 
even hours at a time.

Can you conceive of a variation of your queue->task pool technique that 
might be able to effectively manage such a workload?

The closest I can think of at the moment is hooking into the epoll(2) 
Linux system interface from a "main" task and use the event triggers from 
epoll(2) to execute "work" in a task-pool. I've not come up with an idea 
that could perform well using pure GNAT libraries.


Any suggestions? :)

Cheers

[0] Whereas competition means response-time and number of connections that 
it can handle are roughly equal

-- 
- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler