Poor efficency of Ruby

ruby-talk
41

In data 3/31/2005, "JZ" <spamerom@niet.com> ha scritto:

Dnia Thu, 31 Mar 2005 09:54:23 +0900, Joe Van Dyk napisa³(a):

As I can see, Rails is *not* an application server, as someone mentioned.
It is a couple of Ruby scripts and modules working together. Am I right?

That's correct.

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.

The next version of ruby is meant to be bytecode-interpreted;
there was in fact a short thread about this just today.

The Rails issues you have encountered are also, I believe,
well described on the Rails web page and their mailing list
archives. In all benevolence: a little research (and perhaps
consideration in phrasing your questions) will go a long way.

However, Ruby comes with a web server called Webrick. script/server
starts that web server.

Yes, but Apache is much more powerfull. Those all light embeded httpd
servers included in Ruby (or Python) can be usefull only for testing, not
heavy loaded production sites.

--
JZ

Welcome to ruby!

E

42

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.

···

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.

43

Dnia Thu, 31 Mar 2005 09:54:23 +0900, Joe Van Dyk napisal(a):

As I can see, Rails is *not* an application server, as someone
mentioned. It is a couple of Ruby scripts and modules working
together. Am I right?

That's correct.

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.

This is incorrect. Python scripts that aren't run as .pyc files will
have to be recompiled every time. PHP/Zend has to be configured
correctly. Using Ruby as a CGI does require that the files be
compiled on every read, but this is the same of any .py or .pl or
non-Zend .php file.

Rails works best as if it were an application server using FastCGI
as a backend. With mod_proxy, it is certainly possible to use the
Webrick server as an application server via Apache.

Ruby executes plenty fast, and the script compile step is fast, too.
Consider -- the *whole* of the very high level framework *and
application* represented by Rails compiles in under a second. This
would be like compiling Struts and all sorts of other helper items
from scratch on every call.

The performance you were epxeriencing has nothing to do with Ruby
and everything to do with the depth of the framework that Rails
provides.

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.

Wrong. Pure CGI for *Rails* is useless, but not for many other
things. FastCGI is better than mod_ruby, as far as I can tell.
Additionally, it is my understanding that lighttpd and FastCGI are
even better than Apache, which is a bit of a resource hog. (I'm
looking seriously to see if I need Apache in my servers.)

However, Ruby comes with a web server called Webrick.
script/server starts that web server.

Yes, but Apache is much more powerfull. Those all light embeded
httpd servers included in Ruby (or Python) can be usefull only for
testing, not heavy loaded production sites.

Mmm. Not completely. It depends on *what* your production load is.
Don't make performance assumptions unless you are quite familiar
with your application's needs and your users' profiles.

-austin

···

On Mar 30, 2005 9:24 PM, JZ <spamerom@niet.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

44

Dnia Thu, 31 Mar 2005 13:34:31 +0900, Austin Ziegler napisa³(a):

Python scripts that aren't run as .pyc files will
have to be recompiled every time.

No. Python *automatically compiles* every imported module. It is the
feature of the language.

Rails works best as if it were an application server using FastCGI
as a backend. With mod_proxy, it is certainly possible to use the
Webrick server as an application server via Apache.

Webrick is not only httpd server? It can listen like Webkit on two ports?
Standard Webkit listen at port 8086 (to that port adapter redirect requests
from apache). Webkit can listen also on another port as httpd. Then port
8086 is used internaly.

Ruby executes plenty fast, and the script compile step is fast, too.
Consider -- the *whole* of the very high level framework *and
application* represented by Rails compiles in under a second.

Not for my win32 box. I will change to fcgi and maybe lighthttpd...

FastCGI is better than mod_ruby, as far as I can tell.

Why? For the same Apache, mod_ruby works slower than fcgi?

Additionally, it is my understanding that lighttpd and FastCGI are
even better than Apache

Hmm, it is interesting.

Yes, but Apache is much more powerfull. Those all light embeded
httpd servers included in Ruby (or Python) can be usefull only for
testing, not heavy loaded production sites.

Mmm. Not completely. It depends on *what* your production load is.
Don't make performance assumptions unless you are quite familiar
with your application's needs and your users' profiles.

I assumed many (over 100) concurent request per second.

···

--
JZ

45

Jim Burton ha scritto:

which doesn't make it an application server (not on this side of the
mirror anyway).

on tyhis side of the mirror application server is a buzzword and actually mean nothing, but I wanted to notice that Cerise and Radical aim to be J2EE-like appservers redone in ruby.

46

Er. Not true. When you load a file in Python, it is interpreted and
becomes part of the current program. It isn't compiled to bytecode so
that the bytecode can be used next time for faster load.

···

On Thu, 31 Mar 2005 15:24:45 +0900, JZ <spamerom@niet.com> wrote: > Dnia Thu, 31 Mar 2005 13:34:31 +0900, Austin Ziegler napisał(a):

No. Python *automatically compiles* every imported module. It is the
feature of the language.

--
$stdout.sync = true
"Just another Ruby hacker.".each_byte do |b|
  ('a'..'z').step do|c|print c+"\b";sleep 0.007 end;print b.chr
end; print "\n"

47

Dnia Thu, 31 Mar 2005 18:34:17 +0900, Bill Atkins napisa³(a):

No. Python *automatically compiles* every imported module. It is the
feature of the language.

Er. Not true. When you load a file in Python, it is interpreted and
becomes part of the current program. It isn't compiled to bytecode so
that the bytecode can be used next time for faster load.

This is *not true*. Did you check it? I bet you don't.

dir

2005-03-31 14:37 <DIR> .
2005-03-31 14:37 <DIR> ..
2005-03-31 14:36 16 file1.py
2005-03-31 14:37 27 file2.py

type file1.py

x = "I'm file 1"

type file2.py

import file1
print file1.x

file2.py
I'm file 1
dir

2005-03-31 14:37 <DIR> .
2005-03-31 14:37 <DIR> ..
2005-03-31 14:36 16 file1.py
2005-03-31 14:37 163 file1.pyc
2005-03-31 14:37 27 file2.py

As you can see, file1.pyc is created automatically. Check it. You are wrong
for sure.

···

--
JZ

48

You are indeed correct. My mistake. I have never actually written
any libraries in python, but had never seen Python do this when
compiling scripts (that is, files that didn't get imported).

Bill Atkins

···

On Thu, 31 Mar 2005 21:44:50 +0900, JZ <spamerom@niet.com> wrote: > Dnia Thu, 31 Mar 2005 18:34:17 +0900, Bill Atkins napisał(a):

>> No. Python *automatically compiles* every imported module. It is the
>> feature of the language.
>
> Er. Not true. When you load a file in Python, it is interpreted and
> becomes part of the current program. It isn't compiled to bytecode so
> that the bytecode can be used next time for faster load.

This is *not true*. Did you check it? I bet you don't.

> dir
2005-03-31 14:37 <DIR> .
2005-03-31 14:37 <DIR> ..
2005-03-31 14:36 16 file1.py
2005-03-31 14:37 27 file2.py

> type file1.py
x = "I'm file 1"

>type file2.py
import file1
print file1.x

> file2.py
> I'm file 1
> dir
2005-03-31 14:37 <DIR> .
2005-03-31 14:37 <DIR> ..
2005-03-31 14:36 16 file1.py
2005-03-31 14:37 163 file1.pyc
2005-03-31 14:37 27 file2.py

As you can see, file1.pyc is created automatically. Check it. You are wrong
for sure.

--
JZ

--
$stdout.sync = true
"Just another Ruby hacker.".each_byte do |b|
  ('a'..'z').step do|c|print c+"\b";sleep 0.007 end;print b.chr
end; print "\n"