[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Poor efficency of Ruby...

JZ

3/30/2005 10:58:00 AM

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
47 Answers

David Heinemeier Hansson

3/30/2005 11:24:00 AM

0

> 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.basec... -- Web-based Project Management
http://www.rubyon... -- Web-application framework for Ruby
http://www.loudthi... -- Broadcasting Brain



JZ

3/30/2005 11:55:00 AM

0

Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson napisa3(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. :(

--
JZ

Robert McGovern

3/30/2005 12:13:00 PM

0

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

There is for Apache 2:

http://rubyforge.org/projects/ruby...

Works well enough.


jim burton

3/30/2005 12:50:00 PM

0

On Wed, 30 Mar 2005 19:59:45 +0900, JZ <spamerom@niet.com> wrote:
> 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.

> --
> JZ
>
>


Austin Ziegler

3/30/2005 1:25:00 PM

0

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

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
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca


Stefan Kaes

3/30/2005 1:38:00 PM

0

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

-- Stefan Kaes



khaines

3/30/2005 1:51:00 PM

0

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.

Austin Ziegler

3/30/2005 2:02:00 PM

0

On Wed, 30 Mar 2005 22:49:45 +0900, Kirk Haines <khaines@enigo.com>
wrote:
> 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*:

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
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca


khaines

3/30/2005 2:29:00 PM

0

Austin Ziegler wrote:

> 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

Dick Davies

3/30/2005 2:45:00 PM

0

* 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