Poor efficency of Ruby...

J

JZ

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

David Heinemeier Hansson

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

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. 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. :(
 
J

Jim Burton

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

Austin Ziegler

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

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

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
 
S

Stefan Kaes

David said:
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
 
K

Kirk Haines

Austin said:
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.
 
A

Austin Ziegler

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*:

Um. Neat, but not quite what I meant ;)

I'd love to have a framework that can run as app.cgi without
independent processes.

It won't matter much for me as I move forward, as I have a host
where I can run persistent processes, but not everyone has that
luxury.

-austin
 
K

Kirk Haines

Austin said:
Um. Neat, but not quite what I meant ;)

Ah! I thought you simply meant without the use of fastcgi or mod_ruby, and
with decent (for CGI) performance. :)
I'd love to have a framework that can run as app.cgi without
independent processes.

The difficulty is that a framework implies a lot more stuff than, say, a
templating system, and some of that stuff takes some work to set itself up.

Take a templating system (Chris N's Kashmir, or Amrita2, or xtemplate, or
whatever), and run that with plain CGI, and performance will be fine, but
that's only a fraction of what a full framework delivers. Mix in some sort
of session handling, like from CGI::Session, and you're capability expand,
and startup time for a plain CGI still isn't bad. Start rolling in an ORM,
though, and things start slowing down because even the simplest ORMs do
quite a bit of dynamic setup at the start.

Still, for a db schema that's not large or complex, one could easily roll a
"framework" out of off the shelf tools like Kashmir, CGI::Session, and
Kansas (mentioned simply because I know it's startup can be fast; Og or AR
may work just as quickly for simple schema)and get adequate CGI-only
performance. It won't have all of the bells and whistles that something
else might provide, but one would have an effective fraction of bells and
whistles without incurring high startup costs.


Just theorizing,

Kirk Haines
 
D

Dick Davies

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


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?
 
M

Michael Campbell

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

Aredridel

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


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

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
 
L

Lothar Scholz

Hello JZ,

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

J> Is it not strange? CGI PHP works quite fast. CGI adapter for pythonic
J> 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.

J> What's wrong with Ruby and CGI?

Not very much.
 
J

Jeremy Kemper

Aredridel said:
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
 
I

Iwan van der Kleyn

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 :)

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
 
I

Iwan van der Kleyn

JZ said:
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.
 
J

JZ

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

Bill Atkins

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

Bill
 
J

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top