Poor efficency of Ruby

I have prior experiency with php and recently pythonic application servers
(webware, skunkweb, cherrypy). But I found Rails is very interesting
framework and I would like to test it. I have some questions to more
experienced users of Ruby. No offence, I simply want to know answers.

1. Can Ruby compile its modules to bytecode like Python do? I found in
internet comparision Rails against pythonic application server Quixote. It
is strange, how much, much faster Quixote is. I know that Quixote
precompiles its templates to pure python modules (which are automatic
compiled to pythonic bytecode), so for every request nothing has to be
parsed. Is it also possible for Ruby modules?

2. I am testing examples from website of Rails on my WinXP box. I do not
know why, but every request consumes 100% of my CPU and takes several
seconds! I am using simply CGI, but it seems not to be normal even for CGI.
I have the latest Ruby and Rails, 1.5GB RAM and AthlonXP 2800+.

···

--
JZ

1. Can Ruby compile its modules to bytecode like Python do? I found in
internet comparision Rails against pythonic application server Quixote. It
is strange, how much, much faster Quixote is. I know that Quixote
precompiles its templates to pure python modules (which are automatic
compiled to pythonic bytecode), so for every request nothing has to be
parsed. Is it also possible for Ruby modules?

If you read further posts from the author of that comparison, you'll realize that he didn't know head from tail doing that "comparison". He was comparing applications with very different setups (clear text vs textile formatted) and it wasn't even about Rails (he used Instiki which is based on similar ideas, but based on a snapshot of how I thought them to be more than a year ago).

Rails caches the compiled ERb and reuses the structure such that a new run merely requires a run on the passed bindings. But there's no explicit byte code caching beyond whatever Ruby itself may be doing.

2. I am testing examples from website of Rails on my WinXP box. I do not
know why, but every request consumes 100% of my CPU and takes several
seconds! I am using simply CGI, but it seems not to be normal even for CGI.
I have the latest Ruby and Rails, 1.5GB RAM and AthlonXP 2800+.

Rails does a bunch of start-up magic that makes CGI whole-fully unsuitable for anything more than asserting that it works. For development, you should get started using WEBrick, which is no race horse but lots faster than CGI, and for deployment you should get on to FastCGI.

Additionally, Rails has different environments for development and production. The development one is generally about 50% slower than the production one.

There's a bunch of high-profile sites running Ruby on Rails. The usual suspects are Basecamp, 43things, Odeo, Ta-da List, and e-commerce sites like Snowdevil and Bellybutton.

All that being said, we're currently just starting the effort to benchmark and profile Rails. We're somewhat through Make It Work and Make It Right. So its the natural progression to Make It Fast.

But unless you both have incredible performance requirements and no money to spend, you should be more than fine. One guy in Texas built a 10-server Rails cluster to serve 1000+ req/sec dynamic requests for his mortgage processing engine, so unless the value of each request is both incredibly low and uncachable, scaling is not a problem.

···

--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

I have prior experiency with php and recently pythonic application servers
(webware, skunkweb, cherrypy). But I found Rails is very interesting
framework and I would like to test it. I have some questions to more
experienced users of Ruby. No offence, I simply want to know answers.

[snip]
Ruby != Rails - your question is about poor efficiency of Rails.

···

On Wed, 30 Mar 2005 19:59:45 +0900, JZ <spamerom@niet.com> wrote:

--
JZ

JZ wrote:

I found in internet comparision Rails against pythonic application server Quixote. It is strange, how much, much faster Quixote is.

Mike Watkins is the one who published the figures, without really knowing what he was talking about, as he later on admitted.

http://mail.mems-exchange.org/pipermail/quixote-users/2005-February/004263.html

http://mikewatkins.net/categories/technical/respondingtoryan.html

I don't think he was spreading FUD deliberately. Just the whole "Rails thing" makes the average Pythonista really nervous.

David Heinemeier Hansson wrote:

Rails caches the compiled ERb and reuses the structure such that a new
run merely requires a run on the passed bindings. But there’s no
explicit byte code caching beyond whatever Ruby itself may be doing.

I always assumed that would be the case. It is, however, not entirely
true. At the moment it just caches the source code of the compiled ERb
and does an eval on that, which means it will be reparsed on each
request. But there is a patch available here:
http://dev.rubyonrails.org/ticket/912

– Stefan Kaes

Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson napisa³(a):

Rails does a bunch of start-up magic that makes CGI whole-fully
unsuitable for anything more than asserting that it works.

Is it not strange? CGI PHP works quite fast. CGI adapter for pythonic
applications server Webware works even very fast. What's wrong with Ruby
and CGI? If it is so unuitable there should be warnings not to use CGI for
Rails at all. I set up first simple Rails using examples from the web. Why
every request consumes 100% of my AthlonXP 2800+ and takes so meny seconds?
I have enough RAM, fast (RAID stripe) disks.

It is a pity there is no binary version of mod_ruby for win32. I can find
only source tarballs. :frowning:

···

--
JZ

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

I don't think he was spreading FUD deliberately. Just the whole "Rails
thing" makes the average Pythonista really nervous.

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.

···

--
JZ

It is a pity there is no binary version of mod_ruby for win32. I can find
only source tarballs. :frowning:

There is for Apache 2:

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

Works well enough.

There is no problem with Ruby and CGI (or much of anything else).
Ruwiki is a decently fast wiki application written in Ruby. There is
a problem with Rails and CGI, because the basic philosophy of Rails
is different.

Rails is best considered an application server, and as such is
expected to be running on your system full time (as far as I can
tell, it doesn't). Otherwise, you have to go through its extensive
compile process every time -- no, Ruby doesn't do bytecodes or
bytecode caching at this point.

Rails focusses on making the developer's job easier by making the
application easier to understand.

I'd love to be corrected, but I'm not sure that there's a "good"
CGI-friendly application framework for Ruby.

-austin

···

On Wed, 30 Mar 2005 20:54:45 +0900, JZ <spamerom@niet.com> wrote:

Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson
napisal(a):

Rails does a bunch of start-up magic that makes CGI whole-fully
unsuitable for anything more than asserting that it works.

Is it not strange? CGI PHP works quite fast. CGI adapter for
pythonic applications server Webware works even very fast. What's
wrong with Ruby and CGI? If it is so unuitable there should be
warnings not to use CGI for Rails at all. I set up first simple
Rails using examples from the web. Why every request consumes 100%
of my AthlonXP 2800+ and takes so meny seconds? I have enough RAM,
fast (RAID stripe) disks.

It is a pity there is no binary version of mod_ruby for win32. I
can find only source tarballs. :frowning:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

* JZ <spamerom@niet.com> [0354 12:54]:

Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson napisa?(a):

> Rails does a bunch of start-up magic that makes CGI whole-fully
> unsuitable for anything more than asserting that it works.

Is it not strange? CGI PHP works quite fast. CGI adapter for pythonic
applications server Webware works even very fast.

Yeah, but a CGI tomcat would be a bit sluggish. What's your point?

···

--
'With that big new contract, I've been able to make those government mandated
upgrades you've all been suing me about.'
    -- Prof. Farnsworth
Rasputin :: Jack of All Trades - Master of Nuns

Comparing apples to oranges.

PHP is lightning fast to parse: It's parser-friendly first, and
human-friendly second. Python the same. Any use of Ruby where you parse
on every step will be a bit slower than PHP or Python for identical
code. (I have an easier time optimizing Ruby cleanly though....)

Comparing a tiny stub for a persistent app process to the whole Rails
app is apples to oranges, too. A fair comparison of Ruby to Webware
would likely be to compare IOWA using the CGI stub to Webware using the
CGI stub.

If you set up Rails as a FastCGI process, you'll see the parsing penalty
go away largely. You should be able to find mod_fastcgi or mod_fcgid for
windows apache without too much trouble, and as far as I know, lighttpd
runs on Windows too.

If you're seeing 100% CPU usage for several seconds, though, that
doesn't sound right. Even CGI isn't that bad in my experience. You might
do a little profiling to see where it spends its time.

Ari

···

On Wed, 2005-03-30 at 20:54 +0900, JZ wrote: > Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson napisał(a):

> Rails does a bunch of start-up magic that makes CGI whole-fully
> unsuitable for anything more than asserting that it works.

Is it not strange? CGI PHP works quite fast. CGI adapter for pythonic
applications server Webware works even very fast. What's wrong with Ruby
and CGI? If it is so unuitable there should be warnings not to use CGI for
Rails at all. I set up first simple Rails using examples from the web. Why
every request consumes 100% of my AthlonXP 2800+ and takes so meny seconds?
I have enough RAM, fast (RAID stripe) disks.

It is a pity there is no binary version of mod_ruby for win32. I can find
only source tarballs. :frowning:

Hello JZ,

Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson napisa³(a):

Rails does a bunch of start-up magic that makes CGI whole-fully
unsuitable for anything more than asserting that it works.

Is it not strange? CGI PHP works quite fast. CGI adapter for pythonic
applications server Webware works even very fast.

Ummm....
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.

What's wrong with Ruby and CGI?

Not very much.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

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

Bill

···

On Thu, 31 Mar 2005 05:24:44 +0900, JZ <spamerom@niet.com> wrote: > Dnia Wed, 30 Mar 2005 21:56:37 +0200, Iwan van der Kleyn napisał(a):

> I don't think he was spreading FUD deliberately. Just the whole "Rails
> thing" makes the average Pythonista really nervous.

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.

--
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"

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

Quit being so supersensitive. :slight_smile:

···

On Thu, 31 Mar 2005 05:24:44 +0900, JZ <spamerom@niet.com> wrote: > Dnia Wed, 30 Mar 2005 21:56:37 +0200, Iwan van der Kleyn napisał(a):

> I don't think he was spreading FUD deliberately. Just the whole "Rails
> thing" makes the average Pythonista really nervous.

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.

Austin Ziegler wrote:

I'd love to be corrected, but I'm not sure that there's a "good"
CGI-friendly application framework for Ruby.

IOWA can be used via plain CGI adequately.

IOWA runs as one (or more) persistent processes, so the CGI program is
merely a transport proxy, and is pretty simple*:

···

-----
require 'iowa/Client'
iowa_socket = '[REPLACE_WITH_SOCKET_DEF]'
client = Iowa::Client.new(iowa_socket)
client.handle_request
-----

Kirk Haines

* This will become slightly more complicated with the upcoming release.
There have been huge developments in preparation for reaching version 1.0,
and among these are the ability to run multiple backends to allow trivial
scaling of performance. The above CGI program doesn't support multiple
backend access, so may grow by a line or two in order to do so.

This is starting to sound more troll-ish by the second; "I really WANT
to like <ruby, or whatever>, but it just doesn't do <x>..."

Then again, I'm a cynic.

Aredridel wrote:

If you're seeing 100% CPU usage for several seconds, though, that
doesn't sound right. Even CGI isn't that bad in my experience. You might
do a little profiling to see where it spends its time.

I profiled Rails + CGI when I was starting out. RubyGems accounts for
the largest chunk of the load time. Put the Rails libraries you'd like
to use in your vendor dir and use "normal" requires for a nice pick-me-up.

jeremy

Comparing apples to oranges.

PHP is lightning fast to parse: It's parser-friendly first, and
human-friendly second. Python the same.

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

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".

Regrds,

Iwan

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

There is no problem with Ruby and CGI (or much of anything else).
Ruwiki is a decently fast wiki application written in Ruby. There is
a problem with Rails and CGI, because the basic philosophy of Rails
is different.

Rails is best considered an application server, and as such is
expected to be running on your system full time (as far as I can
tell, it doesn't). Otherwise, you have to go through its extensive
compile process every time -- no, Ruby doesn't do bytecodes or
bytecode caching at this point.

I sth do not understand. Did I really 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.
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.

···

--
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.

···

--
JZ