Dnia Wed, 30 Mar 2005 21:13:04 +0900, Robert McGovern napisa³(a):
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/rubyforapache/
Works well enough.
Tnx. I will try again with mod_ruby.
--
JZ
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
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*:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
CGI is merely the protocol your web browser is using to communicate
with the Rails server. You are absolutely using CGI.
Bill
On Thu, 31 Mar 2005 05:14:45 +0900, JZ <spamerom@niet.com> wrote: > 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
--
$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"
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
On Thu, 31 Mar 2005 05:24:45 +0900, JZ <spamerom@niet.com> wrote: > 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
--
$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"
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
On Thu, 31 Mar 2005 04:49:52 +0900, Iwan van der Kleyn <none@none.net> wrote:
> 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".
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.
PGP.sig (194 Bytes)
On 30 Mar 2005, at 12:14, JZ wrote: > Dnia Wed, 30 Mar 2005 22:24:30 +0900, Austin Ziegler napisał(a):
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
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
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?
--
JZ
Hi,
On Thu, 31 Mar 2005 05:34:45 +0900, JZ <spamerom@niet.com> wrote: > 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?
Do you know about FastCGI?
Cheers,
Joao
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?
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.
Dnia Thu, 31 Mar 2005 05:44:25 +0900, Joao Pedrosa 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?
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
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.
--
JZ
Dnia Thu, 31 Mar 2005 05:44:25 +0900, Joao Pedrosa 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?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
From: "JZ" <spamerom@niet.com>
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.
--
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
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 actionAfter 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
That's correct.
However, Ruby comes with a web server called Webrick. script/server
starts that web server.
On Thu, 31 Mar 2005 08:54:44 +0900, JZ <spamerom@niet.com> wrote: > 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?
To be specific, I said that Rails is *like* an appserver. Not that it is.
-austin
On Mar 30, 2005 6:54 PM, JZ <spamerom@niet.com> wrote:
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?
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Which serves an application
On Thu, 31 Mar 2005 09:54:23 +0900, Joe Van Dyk <joevandyk@gmail.com> wrote:
> 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.
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.
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
which doesn't make it an application server (not on this side of the
mirror anyway).
On Thu, 31 Mar 2005 10:29:24 +0900, Douglas Livingstone <rampant@gmail.com> wrote:
On Thu, 31 Mar 2005 09:54:23 +0900, Joe Van Dyk <joevandyk@gmail.com> wrote:
> > 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
