Poor efficency of Ruby...

[JZ]

Dnia Thu, 31 Mar 2005 01:58:38 +0900, Lothar Scholz napisa³(a):

The CGI adapter for Webware is just a wrapper that passes arguments to
the Server, nothing that has something to do with CGI and your web
application run/startup time. Starting Webware takes much more time then
starting a webrick rails server.

OK. So what is started after "ruby.exe scripts/server"? It looks like
standalone process of.. Rails? I don't understand it.

 

[Bill Atkins]

Iwan was referring to a weblog post, not to you.

Bill

 

[JZ]

Dnia Wed, 30 Mar 2005 21:13:04 +0900, Robert McGovern napisa³(a):

There is for Apache 2:

http://rubyforge.org/projects/rubyforapache/

Works well enough.

Tnx. I will try again with mod_ruby.

 

[Bill Atkins]

There is a server written in Ruby called WEBrick. When you run
scripts/server, you're starting a WEBrick server for your Rails
application. In production environments, WEBrick is generally not
used - the most common setup is FastCGI with lighttpd or Apache.
WEBrick is strictly for testing, from what I understand.

Bill

 

[JZ]

Dnia Thu, 31 Mar 2005 05:23:08 +0900, Bill Atkins napisa³(a):

CGI is merely the protocol your web browser is using to communicate
with the Rails server. You are absolutely using CGI.

The basic philosophy of CGI is to execute for every request interpreter of
(Ruby/PHP/Perl/Python whatever) and its scripts (or binary compiled
application) all over again. This is the reason CGI is slow. But here I am
connecting to Rails server through Apache. CGI is only a protocol as you
wrote. It should be fast, because CGI is only an adapter (if I understand
it correctly) Where am I wrong?

 

[Joao Pedrosa]

Hi,

Dnia Thu, 31 Mar 2005 05:23:08 +0900, Bill Atkins napisa³(a):


The basic philosophy of CGI is to execute for every request interpreter of
(Ruby/PHP/Perl/Python whatever) and its scripts (or binary compiled
application) all over again. This is the reason CGI is slow. But here I am
connecting to Rails server through Apache. CGI is only a protocol as you
wrote. It should be fast, because CGI is only an adapter (if I understand
it correctly) Where am I wrong?

Do you know about FastCGI?

Cheers,
Joao

 

[Aredridel]

Mmh, I think you have got you fruit mixed up in the wrong bowl

Its rather silly to state that Python is "parser-friendly first, and
human-friendly second". Python's principal characteristic. its use of
white-space to delimit program blocks, is primarily intended to make the
language more us "human-friendly". That¶ why Python is often called
"executable pseudo-code".

If so, I feel it fails (hence, I use Ruby). But that's just trollish.

What I mean is that there's not much lexical ambiguity, so python can
parse simply and concretely without parser complexity. () indicate a
call, indentation is easy to parse for nesting. The language is fairly
regular, and while I'm not sure if it's LALR(1), it's darn close. Ruby
is not.

As far as executable pseudocode, I'd argue that it's not, but then, I
find Python ugly.

Ari

 

[Joe Van Dyk]

Dnia Wed, 30 Mar 2005 21:56:37 +0200, Iwan van der Kleyn napisa³(a):


You guys must be supersensitive. I have nothing against ruby. I try to
understand the way it works. I am just trying to test Ruby and Rails. I
found its very poor performance on my Win32 box. I had no idea why, so I
started this thread here. Take it easy.

Iwan wasn't talking about you, he was talking about Mike Watkins, as
should've been obvious from his post.

Quit being so supersensitive.

 

[JZ]

Dnia Thu, 31 Mar 2005 05:44:25 +0900, Joao Pedrosa napisa³(a):

Do you know about FastCGI?

Yes, I know. But what about my question? Where am I wrong? Even classic cgi
script working as a simple adapter between Apache and application server
can be very fast.

 

[Bill Kelly]

Dnia Thu, 31 Mar 2005 05:44:25 +0900, Joao Pedrosa napisa³(a):


Yes, I know. But what about my question? Where am I wrong? Even classic cgi
script working as a simple adapter between Apache and application server
can be very fast.

How does it perform without Apache involved? Can you run the program directly
from the command line? ruby my_cgi_adaptor_script.rb .... ?

If it's still slow, maybe it will be easier to find where the time is going by
eliminating Apache entirely for debugging purposes.

Just a thought,

Regards,

Bill

 

[David Heinemeier Hansson]

Yes, I know. But what about my question? Where am I wrong? Even

classic cgi
script working as a simple adapter between Apache and application
server
can be very fast.

There's no connection between the CGI gateway and the ./script/server.

This is what happens on every single CGI request:

1) Require the entire Rails framework
2) Configure the Rails classes according to the environment
3) Load your application classes
4) Perform the action

After which all that hard work in 1-3 is thrown away. Running with
FastCGI, you experience 1-3 once, and just do 4 over and over again.

When you run ./script/server, you're starting a separate webserver
running by default on port 3000. It's a lot faster than CGI, but also a
lot slower than FastCGI. For most people, it's just fine for
development.

 

[Eric Hodel]

--Apple-Mail-3-775062971
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=EUC-KR; format=flowed

Dnia Wed, 30 Mar 2005 22:24:30 +0900, Austin Ziegler napisa=A9=A9(a):


I sth do not understand. Did I really execute Rails through CGI???

Yes, you really did execute Rails through CGI.

I thought I executed long-running process of Rails through "ruby.exe
scripts\server" command. And CGI, as I thought, was only small adapter
between Apache and Rails application server.

scripts/server is just a WEBrick server primarily for development=20
purposes. CGI has no relation to it, but you can proxy requests from=20
Apache to WEBrick using mod_proxy. None of this is set up by default,=20=

since there are more efficient ways of avoiding the startup cost (like=20=

FastCGI mode).

E.g. Webware can work in that way. CGI is used only as a bridge = between
Apache and long-running Webkit applications server. It works very =

fast.

Rails could support this type of thing, but FastCGI is a more general=20
solution.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-3-775062971
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkJLOckACgkQMypVHHlsnwSySACaAsxfVa5Ft0lGmiVjemyVWJsp
e54AoN9yVM1E6otGMX1KnDpT1j01cJlp
=HywC
-----END PGP SIGNATURE-----

--Apple-Mail-3-775062971--

 

[JZ]

Dnia Thu, 31 Mar 2005 08:38:30 +0900, David Heinemeier Hansson napisa³(a):

There's no connection between the CGI gateway and the ./script/server.

This is what happens on every single CGI request:

1) Require the entire Rails framework
2) Configure the Rails classes according to the environment
3) Load your application classes
4) Perform the action

After which all that hard work in 1-3 is thrown away. Running with
FastCGI, you experience 1-3 once, and just do 4 over and over again.

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?

 

[Joe Van Dyk]

Dnia Thu, 31 Mar 2005 08:38:30 +0900, David Heinemeier Hansson 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.

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

 

[Charles Steinman]

The basic philosophy of CGI is to execute for every request interpreter of
(Ruby/PHP/Perl/Python whatever) and its scripts (or binary compiled
application) all over again. This is the reason CGI is slow. But here I am
connecting to Rails server through Apache. CGI is only a protocol as you
wrote. It should be fast, because CGI is only an adapter (if I understand
it correctly) Where am I wrong?

You are mistaken in your belief that you are "connecting to a Rails
server through Apache." Rails is a Ruby program that servers can run
(to be super-simple about it). With CGI, this program will be run once
for every request, with all the overhead associated with that. This is
why the Rails site pushes FastCGI so much: It keeps a persistent
instance of the Ruby interpreter around so you can have the kind of
architecture you're thinking of.

 

[Douglas Livingstone]

That's correct.

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

Which serves an application

 

[Jim Burton]

Which serves an application

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

 

[JZ]

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

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.

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]

Dnia 30 Mar 2005 17:28:36 -0800, Charles Steinman napisa³(a):

With CGI, this program will be run oncefor every request, with all the
overhead associated with that. This is why the Rails site pushes FastCGI
so much: It keeps a persistent instance of the Ruby interpreter around
so you can have the kind of architecture you're thinking of.

No, FCGI does not make it an appplication server. It is faster only because
Ruby interpreter is in memory all the time. The same can be done using
mod_ruby and it may be even faster than FCGI.

For application server all scrips (servlets) are in memory all the time. If
they are precompiled, response may be very fast. I tested Webware against
PHP and Webware was up to even 6x times faster than similar PHP code.
Application server is an long running multithreading (or forking)
application. E.g. free and very fast application server Skunkweb
(skunkweb.sf.net) can even share its cached components with other servers.

 

[Saynatkari]

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


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.

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.

Welcome to ruby!

E