[ruby-talk:14906] Re: Ruby and Web Applications

(ObNote: Can we tone it down a little?)

Todd Gillespie <[e-mail]> wrote:
>MJ Ray <[e-mail]> wrote:
>: You're missing the overheads from the compilation and lack of caching.
>: An app server app only has to be loaded once, rather than
>: reinterpreted each time the page is executed, and it can cache the
>: results of the intermediate stages.
>
>Umm.. no.  Overhead from compiliation is in my little table, under
>'compiled scripts'.  That's sort of the point of embedded scripting, and
>the primary difference from CGI.

I thought that the main point of embedded scripting is to
reduce startup costs such as launching a new process and
opening database connections.  That is the primary difference
from CGI, and those two items are the majority of the
performance boost that you can gain.  (They are not the be all
and end all of what you can do, of course.)

>Caching is in no way limited to application servers; I use caching all
>the time in Aolserver, which we would best describe as an embedded Tcl
>scripting webserver.
>
>I think we are either using different terminology or you are unfamiliar
>with this problem domain.

I think that you are reading what he wrote uncharitably.  Read
his next paragraph:

>: Although embedded scripting can work around these, it usually doesn't.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>: If it's built into the framework of a good app server, you get them
>: every time.

He is well aware of the fact that you *can* make embedded
scripting avoid compilation and caching.  He is saying that
usually they don't.  And that is a claim I have to admit to
agreeing with.  For instance in the mod_perl world people
tend to take CGI scripts and use Apache::Registry to speed
them up rather than write real mod_perl handlers.

This is a worthwhile thing to do because you can reuse
database connections and you don't have to launch processes.
However you still compile the script on each request, and
you have no opportunity for caching.  To get those you need
to write real handlers.  But many people don't, and don't
understand that there is a difference to them mod_perl is
mod_perl.

(For those who don't know this area, mod_perl uses an
embedded Perl interpreter in Apache to serve the request.
A mod_perl handler is just a function written in Perl that
is run in Apache, often returning a page like you would
from a CGI script.  Apache::Registry provides a generic
handler that will execute specified CGI scripts by evaling
them into the current process.)

>And we need the overhead of an app server rather than a good
>implementation of embedded Ruby, why, exactly?

You make it sound like these are mutually exclusive
options.  I don't think they are.

There is no reason that both cannot exist.  Furthermore
in practice I don't think there is much of a gap between
Apache with mod_* (written with real handlers) and an
application server.  I don't know Aolserver (though I
know just enough that when you say "Aolserver" and "TCL"
I think, "Ars Digita") but I would expect the same could
be said for it.

If things are done right, I see no reason that expecting
projects to be portable between a webserver with embedded
scripting and a dedicated application server to be
substantially different from supporting two different
webservers with embedded scripting.  If there *is* a major
difference, then the application server is the one that
will probably lose.  (Because the most widely used platform
is probably going to be Apache with mod_ruby.)

Cheers,
Ben