On Thu, Mar 31, 2005 at 11:24:46AM +0900, JZ wrote:
> 
> Now I understand! It may be a reason why any Python (or Java) application
> server will be faster than Ruby ever be. Both use precompiled code and do
> not need to parse source code for every request. Even PHP with its Zend
> eaccelerator will be faster, because it doesn't need to parse over and over
> again the same source files. 
> 
> I think Ruby needs similar solution. If not bytecode (like Java and Python
> use), so maybe accelerator like Zend for PHP? Ruby and Rails works like PHP
> without accelerator. It has to parse all his libraries over and over again
> for every request. So I can conclude that for bigger code all might be
> slowing down... So I understand why using pure CGI for Rails is useless.
> FCGI can help, mod_ruby can help more (I guess), but nothing more.

I'm afraid that you don't really understand.  Rails is an application.
It is designed so that you may run it stand-alone to serve requests
directly as a CGI process or coupled with another piece of software,
such as mod_ruby, FastCGI or Webrick, effectively becoming an
application server (or in the case of mod_ruby, part of the web server).

If run stand-alone, the rails application has to re-do all the prep work
("the magic behind Rails") necessary before serving the request since
there is no persistent application to maintain this information.

If run coupled with something like FastCGI, Webrick, or mod_ruby, this
prep work is only done once.  The application remains running in memory,
maintaining all the "magic".  Each request may then be served
immediately, without having to re-parse the source code, without having
to re-do these "magical" preparations.

The stand-alone method is really only useful in development.  It is
certainly slow.  No one will argue that point.  However, it is NOT the
recommended setup for production.

Imagine if, for every request, Java had to start up its virtual machine,
reload all the class files and libraries, re-load information from the
database, pre-parse templates on the disk, and initialize some lookup
tables before serving the request.  You bet that would be slow.

That's why there are Java application servers like JBoss and WebLogic
which allow the Java applications to preload their classes, read the
database, pre-parse templates, and initialize itself.  Then, when a
request comes in, the application is there, ready to serve your request
immediately.  Have you noticed that these app servers are not so quick
to come up if there's a big application attached?

You can't compare a Java application server to Rails running stand-alone
any more than you can compare Rails running under FastCGI with a Java
application running without the app server.

That said, this is NOT the only way to design an application.  However,
as has been mentioned, the objective of Rails is to do all the tedious
work for you -- the above-mentioned magic -- leaving you time to be
creative and get your project up and running quickly.

Henry.