From: Kirk Haines <khaines@...>
Date: 2004-08-09T23:40:11+09:00
Subject: Re: ANN: Iowa 0.9 Released

On Mon, 9 Aug 2004 23:11:21 +0900, Ara.T.Howard wrote

> so, in essence, the 'middle bit' of mod_ruby, fcgi, or cgi is needed 
> to lookup the iowa persistent process - to find it and connect stdin,
>  stdout, stderr, etc.  you couldn't simply map an apache handler to 
> iowa application since they are persistent and apache would then 
> fire one up for each request...  would it be difficult to use 
> mod_fastcgi to manage the whole thing?  i mean, that module has 
> support to start persistent applications and then direct requests to 
> them via sockets...  (i'm just wondering out loud here)

Yep.  The middle bit is just a transport mechanism to get the request from 
the web server to the Iowa process and back again.

Iowa could definitely be setup to run directly as an FCGI process, too.  I 
should do that, as an option.  Should be pretty trivial to setup.
 
> does the mod_ruby or cgi bit manage initially starting the iowa app, 
> or is this a separate step?

The Iowa app runs as a seperate bit.  This allows some flexibility to, for 
example, run the Iowa process on a seperate machine from the web server.  
Down the road I am planning on making it possible to have multiple Iowa 
processes running across multiple machines for load balancing with session 
affinity, so that fits the model of the Iowa process _generally_ being 
seperate, too.

> so one must avoid doing anything that could potentially block an 
> entire ruby process, like flock, or no new requests would get served 
> - correct?

Hrm.  Yeah.  Interesting point.  I've never had to deal with that problem 
myself, but I can see where it could be troublesome.  One thing I have toyed 
with for about as long as I have been using Iowa is the idea of having as an 
option a forking model instead of a threading model to handle connections.  
With Ruby's all-within-a-process, there would be some potential performance 
advantages to a forking model, especially if it were a forking model with 
preforking.  I just never have done it because I never have needed it.

> this is very cool.

I have it basically done.  There are a few refinements that I want to put 
into it later, but I am going to roll an example usage of it into the 
examples section of the download and release an update today that has this 
inline URL/content generation capability in it.
 
> i like the sound of using webrick, i would assume some sort of 
> handler does away with the need for the mod_ruby/cgi 'middle man'?

Yep.  The model that I used for webrick was to combine the Iowa and WEBrick 
processes.  So you fire up one process, and it serves regular image/static 
HTML/cgi content through WEBrick's regular capabilities, and Iowa content 
goes through the Iowa side of the process.  It is extremely simple to start 
it up.  Take a look at the examples/webrick part of the release.  You should 
be able to just run examples/webrick/iowa_webrick.rb and everything should 
just work.

Performance also seems pretty decent.  I have not tested it extensively, but 
a few quick tests suggest that for Iowa content it's about 70% of the speed 
of apache + mod_ruby, and I assume most of that is simply the difference in 
speed between WEBrick and Apache.  I'll be doing some more extensive tests 
later with larger & more complex content generation, but that sort of speed 
is pretty reasonable.  On a PIII 800Mhz running Gentoo Linux, that 
translates to something in the low 20s of requests per second for a typical 
moderately sized & moderately complex page.
 
> yes.  thank you - i'm going to be doing some web development soon 
> and have been out of that realm for about 12 months, so it's survey 
> time again...

Well, give me a shout if you have any more questions.  I'm always happy to 
give a hand where I can.


Kirk Haines