From: ara.t.howard@... Date: 2007-02-05T01:25:34+09:00 Subject: [OT] Re: Using fork to conserve memory On Sun, 4 Feb 2007, snacktime wrote: > On 2/3/07, ara.t.howard@noaa.gov wrote: >> On Sun, 4 Feb 2007, Rob Sanheim wrote: >> >> > mongrel is still the preferred choice for serving Rails. >> >> why? can you elaborate? > > Well there really aren't that many options to start with. Mongrel works > and is actively maintained. Most of the alternatives have bugs that just > never got fixed, even though some of them like fastcgi or mod_ruby are far > better choices design wise. i thought most of those issue did not apply to linux: for instance the fast_cgi max fds issue was bsd specific wasn't it? the reason i ask is that i've used fastcgi for years on linux servers and never had issues. > The main problem with mongrel isn't mongrel itself, but how you have to use > it. You need a cluster of mongrel processes running with a proxy server in > front. You have issues with proxy servers being able to detect hung > mongrels or sending more then one request at a time to a mongrel. The proxy > servers that can handle those things don't support ssl, and in general it's > just more work to setup and maintain then it could be. ah. > > Threads aren't an option because even if rails was thread safe, you couldn't > use C extensions because of blocking issues, which means most of the > database drivers. And rails makes heavy use of databases. > yes of course. thanks for the info. -a -- we can deny everything, except that we have the possibility of being better. simply reflect on that. - the dalai lama