From: Thomas Hurst <tom.hurst@...>
Date: 2005-06-16T03:09:14+09:00
Subject: Re: Chip Multi-threading and the future

* Eric Hodel (drbrain@segment7.net) wrote:

> For web serving, Rails has primarily uses FastCGI, which is a multi- 
> process model.

No, FastCGI is a client-server model.  A threaded server would be very
nice, although I'm not sure if mod_fastcgi's process manager's aware of
the possibility.  Certainly as an external server a threaded app server
would behave identically to a multi-process one, since it's just bog
standard socket ops.

> 43 Things runs our site off of a 2 CPU box with HT enabled, so we get  
> 4 CPUs.  The multi-process model works great for this, you don't have  
> to worry about threads here because of the way Rails is designed.   

I don't think Rails does anything special here?  As far as FastCGI goes
it works just like any other FastCGI Ruby app.

> You do, however, have to worry about memory.
>
> (It would be nice if you could fork(2) a live Rails process so it  
> wasted less memory, but I think you would loose the benefits of  
> memory savings the first time the GC runs.

You should be able to; I've been planning on adding support for external
servers and enabling libfcgi's preforking stuff in the C extension for
quite a while.  If nothing else you gain proper external server support,
and beyond that there will likely be a lot of sharing with parse trees
and initial data structures.

> But then I need to process the web server's logs, which involves DNS  
> lookups.  This is acceptable but not-so-great because I'm using ruby  
> threads for that, and that probably chews up more CPU than needed  
> switching between the 100 threads.

Are there no async DNS libraries for Ruby about?  Seems a bit overkill
to use a thread just for a DNS lookup.

-- 
Thomas 'Freaky' Hurst
    http://hur.st/