What are the pros & cons of mod_ruby vs fastcgi+ruby? Ruby will most likely be the latest stable snapshot (1.8.2).
The only requirement is the server running Apache 2.x (not 1.3) on Redhat Advanced Server 3.x (kernel 2.4.20-smp).
The site won't be high-volume but it needs to be stable/robust (for a single server website).
I'm getting the impression mod_ruby is a lot easier to setup (super simple apache config). I'd love to hear about any hidden gotchas with either scenario.
Thanks.
mod_ruby:
+ Nice access to Apache internals.
+ Fast.
+ You can write handlers for Apache with it. Handlers can let you do
powerful things.
+ Eruby, if you like that.
+ Easy config.
- Interpreter is shared among all users of mod_ruby. Potential for namespace
clashes because of this.
- mod_ruby is an Apache specfic thing. So your code isn't portable to
other web server types.
fast_cgi:
+ A familiar, conventional CGI-like interface.
+ Fast.
+ Pretty easy to configure this, too, though there is more complexity to
fine tuning it.
+ Many web servers support FastCGI, so your code is more portable.
+ Each seperate FastCGI application is in its own process so no namespace
clashes possible between different applications.
- It IS more complex than mod_ruby.
- Don't have the same level of access to the web server internals.
It's six of one, a half dozen of the other, really. Both work well. Both
can handle busy web sites with good performance and stability. Is there a
particular templating system or web development framework that you want to
use? If so, does it support both of these, or is it better with one of
them? Which one seems more interesting to you? Can some of what you want
to do be done via a handler? Is it important to you to have your code
portable to other web server software?
The answers to those questions may well point you toward one or the other.
Kirk Haines
On Wed, 21 Jul 2004 23:47:03 +0900, Gully Foyle wrote
What are the pros & cons of mod_ruby vs fastcgi+ruby? Ruby will
most likely be the latest stable snapshot (1.8.2).
Neither is very hard to set up in a run-of-the-mill unix environment.
On Wed, 21 Jul 2004 23:47:03 +0900, Gully Foyle <nospam@nospamnospamnospam.com> wrote:
What are the pros & cons of mod_ruby vs fastcgi+ruby? Ruby will most
likely be the latest stable snapshot (1.8.2).The only requirement is the server running Apache 2.x (not 1.3) on
Redhat Advanced Server 3.x (kernel 2.4.20-smp).The site won't be high-volume but it needs to be stable/robust (for a
single server website).I'm getting the impression mod_ruby is a lot easier to setup (super
simple apache config). I'd love to hear about any hidden gotchas with
either scenario.Thanks.
Kirk Haines wrote:
What are the pros & cons of mod_ruby vs fastcgi+ruby? Ruby will most likely be the latest stable snapshot (1.8.2).
mod_ruby:
+ Nice access to Apache internals.
+ Fast.
+ You can write handlers for Apache with it. Handlers can let you do
powerful things.
+ Eruby, if you like that.
+ Easy config.
- Interpreter is shared among all users of mod_ruby. Potential for namespace
clashes because of this.
- mod_ruby is an Apache specfic thing. So your code isn't portable to
other web server types.fast_cgi:
+ A familiar, conventional CGI-like interface.
+ Fast.
+ Pretty easy to configure this, too, though there is more complexity to
fine tuning it.
+ Many web servers support FastCGI, so your code is more portable.
+ Each seperate FastCGI application is in its own process so no namespace
clashes possible between different applications.
- It IS more complex than mod_ruby.
- Don't have the same level of access to the web server internals.It's six of one, a half dozen of the other, really. Both work well. Both can handle busy web sites with good performance and stability. Is there a particular templating system or web development framework that you want to use? If so, does it support both of these, or is it better with one of them? Which one seems more interesting to you? Can some of what you want to do be done via a handler? Is it important to you to have your code portable to other web server software?
The answers to those questions may well point you toward one or the other.
Kirk Haines
Thanks for the great info! It was very helpful.
I think the only remaining question I have is regarding this:
> - Interpreter is shared among all users of mod_ruby. Potential for
> namespace clashes because of this.
I'm not quite sure I understand the nature of the namespace clash in mod_ruby.
When I tried to set a global counter variable just to see what happens, it appears that each instance of apache process gets its own copy. And I was under the impression (I could be totally wrong) that only one request is served up by each process at a time.
Thanks again for the info you've already provided.
On Wed, 21 Jul 2004 23:47:03 +0900, Gully Foyle wrote
Kirk Haines wrote:
fast_cgi:
- It IS more complex than mod_ruby.
Depends on the definition of "complex". I myself see fastcgi as far less complex than Apache+mod_ruby (e.g. compare the number of lines of the code). Plus if you use FastCGI, you don't have to understand Apache API (which can be said to be "complex" too). You only have to understand the CGI protocol, which is understood by perhaps 95-99% of web programmers.
Anoher + for fastcgi: it's easier to use it in a shared hosting environment. Since I provide shared hosting, I currently don't provide mod_perl/mod_php/mod_ruby. PHP runs as a CGI script (with a special module), and all CGI scripts are wrapped to each user's UID. And fastcgi is supported since it's easy to wrap the fcgi scripts using the FastcgiSuexec mechanism.
--
dave
Each seperate Apache process has its own interpreter. However, each of the
different users of mod_ruby within a process share that same interpreter.
So doing something has a global effect in one piece of code can affect the
execution of an unrelated piece of code later.
Since it sounds like you are in control of your own server, this probably
isn't an issue to worry too much about. Just don't use globals much, or if
you do. make sure you are careful with the names, don't modify base classes
in a way in one piece of code that will break another, and generally respect
each piece of code's stomping ground, and you'll be fine.
Kirk Haines
On Thu, 22 Jul 2004 07:47:02 +0900, Gully Foyle wrote
I think the only remaining question I have is regarding this:
> - Interpreter is shared among all users of mod_ruby. Potential
for > namespace clashes because of this.I'm not quite sure I understand the nature of the namespace clash in
mod_ruby.
Kirk Haines wrote:
> fast_cgi:
> - It IS more complex than mod_ruby.Depends on the definition of "complex". I myself see fastcgi as far
less complex than Apache+mod_ruby (e.g. compare the number of lines
of the code). Plus if you use FastCGI, you don't have to understand
Apache API
(which can be said to be "complex" too). You only have to understand
the CGI protocol, which is understood by perhaps 95-99% of web programmers.
I think the use of complex here refers to the overall setup and config.
Neither is very complex, but there are more knobs that can be turned with
FastCGI in the setup.
Anoher + for fastcgi: it's easier to use it in a shared hosting
environment. Since I provide shared hosting, I currently don't
provide mod_perl/mod_php/mod_ruby. PHP runs as a CGI script (with a
special module), and all CGI scripts are wrapped to each user's UID.
And fastcgi is supported since it's easy to wrap the fcgi scripts
using the FastcgiSuexec mechanism.
Definitely. The options when providing shared hosting are to just not worry
about it and hope there are no problems, or to not provide mod_(language)
support. No argument there.
Kirk Haines
On Thu, 22 Jul 2004 17:57:31 +0900, David Garamond wrote
Gully Foyle wrote:
When I tried to set a global counter variable just to see what happens, it appears that each instance of apache process gets its own copy. And I was under the impression (I could be totally wrong) that only one request is served up by each process at a time.
That's true, as each apache instance gets its own interpreter. To keep track of a counter, use some persistant storage, or, my favorite, ruby::Asp
Couldn't a mod_ruby/eruby/asp environment take care of namespace clashes by somehow putting scripts in different applications? As far as I know, I haven't had any such clashes when using perl Apache::Asp.
There are three issues. First, namespaces don't protect you if another
piece of code changes the behavior of Array. This is one issue that Perl
doesn't have because you can't change the behavior of an array like you can
in Ruby.
Second, namespaces don't help your code and some other code use the same
global variable.
And third, namespaces don't help you if someone else's code intentionally
mucks around in your namespace.
In practice, so long as one takes a little care with coding, it is rarely a
problem. In theory, though, especially in a shared hosting environment, it
could be ugly.
Kirk Haines
On Fri, 23 Jul 2004 00:52:19 +0900, David Morton wrote
Couldn't a mod_ruby/eruby/asp environment take care of namespace
clashes by somehow putting scripts in different applications? As far
as I know, I haven't had any such clashes when using perl Apache::Asp.