<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Edho P Arief wrote:
<blockquote
cite="mid:a3780c060904282320s3d500b76jd740a914e948a3a7@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Apr 29, 2009 at 12:41 AM, Guy Naor <a class="moz-txt-link-rfc2396E" href="mailto:guy@mor.ph"><guy@mor.ph></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I didn't say it's better - it's EASIER. The reason it's easier is that the
mod_rails module is the one that actually manages the backend. That means
two major things:
1. You don't need to use mongrel_cluster or a FastCGI launcher
2. When the app die for some reason, the module will handle the relaunching
for you. This eliminate the need for something like monit or a fastcgi
spawner process.
</pre>
</blockquote>
<pre wrap=""><!---->
so basically it's like php-fpm? (and mongrel_cluster is spawn-fgi/php)
</pre>
</blockquote>
It's similar, but the difference is, it's based not on checking
processes and such, but actually managing child processes of the
spawner. When using FastCGI with Rails (I used to do that with
lighttpd) we had the spinner and spawner scripts that checked on the
running processes and relaunched them if they were dead. But mod_rails
actually launches and kills workers based on timeouts and request
logs.. It's smarter in the way it works, and using the global queue
option you can get better predictability with apps having long requests.<br>
<br>
But I still use mongrels in production, launching and controlling them
with monit. I still need to test more on the working of mod_rails to
know for sure it'll meet my production requirements. That's why I said
it's EASIER but didn't say it's better.<br>
<br>
Bye,<br>
<br>
Guy.<br>
<br>
</body>
</html>