From: "Benjamin J. Tilly" Date: 2001-05-09T18:16:23+09:00 Subject: [ruby-talk:14906] Re: Ruby and Web Applications (ObNote: Can we tone it down a little?) Todd Gillespie wrote: >MJ Ray 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