Home
The Toolkit for Online Communities
17243 Community Members, 0 members online, 2115 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Thread safety of OpenACS vs RoR et al. : One Message

Forum OpenACS Development: Re: Thread safety of OpenACS vs RoR et al.

Collapse
Posted by Stan Kaufman on
Apparently a Ruby interpreter is only 20-100K in size, so with FastCGI and reasonable hardware, you can spawn a lot of them without breaking a sweat. So the threaded-vs-forked issue really isn't much of an issue in most web apps.
Collapse
Posted by Andrew Piskorski on
For performance, sure, FastCGI should be good. But I've never yet seen a good explanation of the programming power (or lack there of) of the FastCGI approach (and I've never had a good reason to try it out myself). John Sequeira would probably know.
Collapse
Posted by John Sequeira on
The benefits of FastCGI are mainly simplicity, robustness and portability at the expense of memory use (ie. the multiprocess tax).

You don't have to worry about library thread-safety since you just have a bunch of single-threaded processes. As a result, you can easily do things like run your fcgi processes in a debugger ( I used Komodo + TclPro way back when). I know it's possible to do this in AOLServer, but it's more complicated than hitting the "go" button.

FastCGI's out-of-process architecture is also big win when interfacing with other systems. If any of your external system library code leaks memory or has long-term stability issues you can easily cull processes after a certain number of requests. Not elegant, but when you have code you can't or don't want to maintain that has issues, simply giving it a short halflife works wonders and is not really available as an option in webserver-integrated APIs.

On the flip side, of course, not being integrated means that you have access to no AOLServer (or apache) APIs, just like in CGI. That may or may not be an issue, but I've found it not terribly difficult to emulate the APIs I've needed ( moving ns_schedule* to cron, reimplementing filters).

Going server-api-agnostic means you get to run everywhere - even Microsoft is has gotten the fastcgi bug and will be supporting an ISAPI module (it's in beta.) Even without explicit vendor fcgi support, the cgi-fcgi bridge works great now on every webserver that supports CGI. I'm using it in production at many sites.

I have some small issues with FastCGI, but it has withstood the test of time and continues to do what it was designed to do over a century ago (in web time). Like openacs :-).