[tlug] Re: [RFC] Outline of the fast HTTP talk

[John Fremlin <john@example.com>]

Curt Sampson <cjs@example.com> writes:

> On 2008-11-05 13:41 +0900 (Wed), Edward Middleton wrote:
>
>> Does it make much sense having a single request distributing its
>> processing across more then one core?
>
> Depends on the request. But mongrel processes *all* requests in a
> single Ruby process. Thus, if you have eight cores and are running only
> mongrel, seven of those cores will be idle, no matter what the load on
> your server.

In this very artificial test where there is very limited work being done
in the Ruby process and processing the HTTP headers can (if I understand
correctly) be handled in Mongrels threads, I'm not sure that's true.

Of course, it is true in general, and is one reason people use clusters
of mongrels on one machine.

>>: I could understand this being useful for a CPU intensive task like
>>image processing but for a web server this just seems to be extra
>>overhead.
>
> When you're using a CPU-intensive interpreted language such as Ruby and
> handling hundreds of requests per second, being "just" a web server
> becomes a CPU-intensive task.
>
>> evented_mongrel[1] thin[2] and ebb[3] can handle multiple requests
>> fine without the need for native thread support in Ruby.

I hope to get some numbers out for ebb, but I can't promise anything!

[...]