Poor efficency of Ruby...
JZ
(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
David Heinemeier Hansson
> 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
JZ
> 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
> only source tarballs. :(
There is for Apache 2:
http://rubyforge.org/projects/rubyforapache/
Works well enough.
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.
> --
> JZ
>
>
Austin Ziegler
> Dnia Wed, 30 Mar 2005 20:23:58 +0900, David Heinemeier Hansson
>> 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 * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Stefan Kaes
> 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
Kirk Haines
> 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
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.
Kirk Haines
> 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
> 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
Michael Campbell
to like <ruby, or whatever>, but it just doesn't do <x>..."
Then again, I'm a cynic.
Aredridel
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
Lothar Scholz
J> 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.
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.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Kujawa, Greg
> It is a pity there is no binary version of mod_ruby for win32. I can
> find only source tarballs. :(
Joining in on this a little late, but there is a binary version of this.
Checking out http://rubyforge.org/projects/rubyforapache I downloaded
something I have in place on my Win32 Apache setup. I also added eruby to it
so I can test out things on my local Win32 workstation...
Jeremy Kemper
> 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
Iwan van der Kleyn
>
> 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
Iwan van der Kleyn
> 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.
JZ
> 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
Bill Atkins
Bill
On Thu, 31 Mar 2005 05:24:44 +0900, JZ <spam...@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"
JZ
Tnx. I will try again with mod_ruby.
--
JZ
JZ
> 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
Bill Atkins
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
> 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?
--
JZ
JZ
> 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
Bill Atkins
with the Rails server. You are absolutely using CGI.
Bill
Joe Van Dyk
Iwan wasn't talking about you, he was talking about Mike Watkins, as
should've been obvious from his post.
Quit being so supersensitive. :-)
Aredridel
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
Joao Pedrosa
Do you know about FastCGI?
Cheers,
Joao
JZ
>> 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?
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.
--
JZ
David Heinemeier Hansson
> 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.
--
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
Bill Kelly
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
Eric Hodel
> 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???
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
purposes. CGI has no relation to it, but you can proxy requests from
Apache to WEBrick using mod_proxy. None of this is set up by default,
since there are more efficient ways of avoiding the startup cost (like
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
solution.
--
Eric Hodel - drb...@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
JZ
> 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?
--
JZ
Joe Van Dyk
That's correct.
However, Ruby comes with a web server called Webrick. script/server
starts that web server.
Charles Steinman
JZ wrote:
> 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?
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
> > 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.
Which serves an application :)
Jim Burton
which doesn't make it an application server (not on this side of the
mirror anyway).
JZ
>> 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.
> 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
JZ
> 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.
--
JZ
Saynatkari
In data 3/31/2005, "JZ" <spam...@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
Henry T. So Jr.
>
> 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.
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.
Austin Ziegler
> 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?
To be specific, I said that Rails is *like* an appserver. Not that it is.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Austin Ziegler
> 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.
JZ
> 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
gabriele renzi
>
>
> 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.
Bill Atkins
> 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.
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.
JZ
>> 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
Bill Atkins
any libraries in python, but had never seen Python do this when
compiling scripts (that is, files that didn't get imported).
Bill Atkins