? Ruby through CGI and Rails

Hi everybody,

I am trying to find information on why the cgi interface is obsolete and why everyone is using rails/rack etc. I actually really like rails but can't seem to find the details on why they don't simple run as cgi script. I have a shared cpanel managed domain and setting up rails apps is a piece of cake and in some ways the archecture of rails somehow makes ruby feel more like a application rather that connecting the dots with shtml.

I understand the "cost" of forking process's server side, i also understand the security implications of having your own process!

Perhaps these questions should go to different list but i thought in context to my original query they are relevant.

Does rails exec and sleep in memory but never die. Does each connected user "share" that process ?

Thanks in advance

I would not consider CGI obsolete. Unless you are referring to ruby's
CGI library. In which case, I still wouldn't consider it obsolete, but
because of rails I imagine it has fallen out of preference. (though I
don't know what the rails equivalent is, I'm sure there is an
alternative in the rails world).

I think a lot of people come to rails because they consider it easier.
I've heard people come to ruby because of rails. That's an argument
that disappoints me; ruby is an excellent language and deserving of more
credit than just rails.

Not being a rails user, the next paragraph may be wrong.
Rails is a framework for web application development. Personally I
don't like the cost of running rails. I understand it does run as its
own server. And code written for rails will not translate because it
relies upon the framework. Conversely, code written in ruby can more
easily be translated to another language if necessary. And rails takes
over storage; my impression is that by default it is easy to use MySQL,
but if you wanted to use mongo instead that would be more difficult.

A straight cgi application need not 'connect the dots with shtml.' This
is the manner in which I use ruby. I write cgi scripts that puts html
to the client. And I use ruby's CGI library to read what gets sent. I
don't use rails or shtml.

···

--
Posted via http://www.ruby-forum.com/.

Shaun Lloyd wrote in post #1061455:

I am trying to find information on why the cgi interface is obsolete and
why everyone is using rails/rack etc. I actually really like rails but
can't seem to find the details on why they don't simple run as cgi
script. I have a shared cpanel managed domain and setting up rails apps
is a piece of cake and in some ways the archecture of rails somehow
makes ruby feel more like a application rather that connecting the dots
with shtml.

I understand the "cost" of forking process's server side, i also
understand the security implications of having your own process!

The cost of starting a Rails app is huge - several seconds of startup
time. You really really don't want to do this from scratch on every
request.

Does rails exec and sleep in memory but never die. Does each connected
user "share" that process ?

Depends how you run it. The normal way is to have a pool of processes
each of which is waiting for a HTTP request. It accepts and processes
one HTTP request, sends the response, then goes back to waiting for
another request.

···

--
Posted via http://www.ruby-forum.com/\.

I would not consider CGI obsolete. Unless you are referring to ruby's
CGI library. In which case, I still wouldn't consider it obsolete, but
because of rails I imagine it has fallen out of preference. (though I
don't know what the rails equivalent is, I'm sure there is an
alternative in the rails world).

I think a lot of people come to rails because they consider it easier.
I've heard people come to ruby because of rails. That's an argument
that disappoints me; ruby is an excellent language and deserving of more
credit than just rails.

I came to ruby because of ruby but found rails to be almost as fundamental
as a linux kernal in a gnu system.

Not being a rails user, the next paragraph may be wrong.
Rails is a framework for web application development. Personally I
don't like the cost of running rails.

I agree totally. And you are wrong a little about Rails because it really feels more
like a religion that a application architecture the way some people take about it.

  I understand it does run as its
own server. And code written for rails will not translate because it
relies upon the framework.

Furthermore you have version to version conflicts.

   Conversely, code weitten in ruby can more
easily be translated to another language if necessary.

This is true to a degree, but their are so many features in ruby
that are simple not found in perl/python or php thus any translation
would need to find patterns in each language do deal with all
the structs that ruby has in it's design, BIG job.

   And rails takes
over storage; my impression is that by default it is easy to use MySQL,
but if you wanted to use mongo instead that would be more difficult.
A straight cgi application need not 'connect the dots with shtml.' This
is the manner in which I use ruby. I write cgi scripts that puts html
to the client. And I use ruby's CGI library to read what gets sent. I
don't use rails or shtml.

Thanks very much for your help Mathew. You seem to be in the minority.

I would appreciate finding out more specifics of such a setup.

Do you have to worry about url's in that do you rewrite to clean up cgi-bin etc. ?

Are you on apache, do you use phusion / fastcgi etc. ?

Have you done a profiling of ruby in relation to speed ?

Thanks!

···

On 21/05/12 21:33, Matthew R Chase wrote:

Shaun Lloyd wrote in post #1061455:

I am trying to find information on why the cgi interface is obsolete and
why everyone is using rails/rack etc. I actually really like rails but
can't seem to find the details on why they don't simple run as cgi
script. I have a shared cpanel managed domain and setting up rails apps
is a piece of cake and in some ways the archecture of rails somehow
makes ruby feel more like a application rather that connecting the dots
with shtml.

I understand the "cost" of forking process's server side, i also
understand the security implications of having your own process!

The cost of starting a Rails app is huge - several seconds of startup
time. You really really don't want to do this from scratch on every
request.

It's a real huge. I did tests locally, cross country and cross continent.
I love ruby and rails but honest ruby on rails has very serious performance issues.
The community seems to be working on the problem with the standard
mix of different solutions being thrown at the issue. I wish them all the
best.

Rails will only get faster, thats for sure. Execution time is not the only benchmark
to be sure, but in web development it is critical if not the most critical issue.

Does rails exec and sleep in memory but never die. Does each connected
user "share" that process ?

Depends how you run it. The normal way is to have a pool of processes
each of which is waiting for a HTTP request. It accepts and processes
one HTTP request, sends the response, then goes back to waiting for
another request.

Any developers working specifically on execution time, optimizations etc would
be great.

Thanks very much for you help Brian.

···

On 22/05/12 03:37, Brian Candler wrote:

Shaun Lloyd wrote in post #1061600:

You seem to be in the minority.

undoubtedly. I love/hate that lots of people love rails.

Do you have to worry about url's in that do you rewrite to clean up
cgi-bin etc. ?

I don't think I've ever worried about URLs. Maybe I don't understand
the question. and I don't use cgi-bin; I've always preferred to put
scripts in the same directory as the rest of the web application.

Are you on apache, do you use phusion / fastcgi etc. ?

apache. I don't use a module for scripts.
AddHandler cgi-script .cgi

Have you done a profiling of ruby in relation to speed ?

not officially and usually not in relation to speed; I periodically
check CPU usage. I keep a loose eye on speed as I watch load times.
I've never had lag I couldn't repair by reducing trips to the server or
fixing some storage index.

I have done some spot-checking of efficiency since I first used ruby. I
came to ruby from perl because I got tired of OOP as an afterthought.
At the time I surveyed ruby and PHP as alternatives. The same algorithm
for communication with a device through a serial port ran 30% CPU in PHP
and 0% in ruby. I suspect this is more a credit to the quality of the
ruby community than the language itself. I also check efficiency
periodically to see how scripts contend with volume usage or when I
think I'll have an expensive script. I can't recall ever being
disappointed by the results.

···

--
Posted via http://www.ruby-forum.com/\.

Shaun Lloyd wrote in post #1061602:

understand the security implications of having your own process!

The cost of starting a Rails app is huge - several seconds of startup
time. You really really don't want to do this from scratch on every
request.

It's a real huge. I did tests locally, cross country and cross
continent.
I love ruby and rails but honest ruby on rails has very serious
performance issues.

That just means you're using it wrong. Rails was *never* intended to be
run as a CGI, it's just a ridiculuous thing to do. Run Rails as a
persistent webserver and proxy to it; or run it under Apache using
Phusion Passenger, which will also run any other Rack-based application.

You might get away with running a smaller framework like Sinatra as a
CGI, but it will still have a poor response time. Remember that if you
are using a database, it will need to make a fresh connection to the
database for every request too.

Anyway, this is the wrong mailing list for discussing Rails. Rails is
not Ruby, and this is the Ruby mailing list.

Regards,

Brian.

···

On 22/05/12 03:37, Brian Candler wrote:

--
Posted via http://www.ruby-forum.com/\.

Shaun Lloyd wrote in post #1061602:
>>> understand the security implications of having your own process!
>> The cost of starting a Rails app is huge - several seconds of startup
>> time. You really really don't want to do this from scratch on every
>> request.
>>
> It's a real huge. I did tests locally, cross country and cross
> continent.
> I love ruby and rails but honest ruby on rails has very serious
> performance issues.

That just means you're using it wrong. Rails was *never* intended to be
run as a CGI, it's just a ridiculuous thing to do. Run Rails as a
persistent webserver and proxy to it; or run it under Apache using
Phusion Passenger, which will also run any other Rack-based application.

At the end of the day, look at what rack is using. CGI. It is a realization
that really threw me for a loop for a while.

Andrew McElroy

···

On Wed, May 23, 2012 at 4:36 AM, Brian Candler <lists@ruby-forum.com> wrote:

> On 22/05/12 03:37, Brian Candler wrote:

Regards,

Brian.

--
Posted via http://www.ruby-forum.com/\.

Shaun Lloyd wrote in post #1061600:

You seem to be in the minority.

undoubtedly. I love/hate that lots of people love rails.

Do you have to worry about url's in that do you rewrite to clean up
cgi-bin etc. ?

I don't think I've ever worried about URLs. Maybe I don't understand
the question. and I don't use cgi-bin; I've always preferred to put
scripts in the same directory as the rest of the web application.

It's actually the fastest method of all, at least with the parameters i'm benchmarking.

Are you on apache, do you use phusion / fastcgi etc. ?

apache. I don't use a module for scripts.
AddHandler cgi-script .cgi

Yeah i figured that one out just on your inference (Thanks heaps). I actually went a bit to far
when i learned how easy apache makes the setup of handlers, but thats another thread.

Have you done a profiling of ruby in relation to speed ?

not officially and usually not in relation to speed; I periodically
check CPU usage. I keep a loose eye on speed as I watch load times.
I've never had lag I couldn't repair by reducing trips to the server or
fixing some storage index.

I have done some spot-checking of efficiency since I first used ruby. I
came to ruby from perl because I got tired of OOP as an afterthought.
At the time I surveyed ruby and PHP as alternatives. The same algorithm
for communication with a device through a serial port ran 30% CPU in PHP
and 0% in ruby.

One thing i will say for php is that it's fast for dumping text.Don't think their would be a second thing.
Oh yeah it runs wikipedia (thanks for that :slight_smile:

   I suspect this is more a credit to the quality of the
ruby community than the language itself. I also check efficiency
periodically to see how scripts contend with volume usage or when I
think I'll have an expensive script. I can't recall ever being
disappointed by the results.

Ruby has alot more noise to be heard, that is for sure. The community is really
helpful as well. I've posted a few places with initial learning issues. I'm well on my
way now. Thanks heaps.

···

On 22/05/12 20:48, Matthew R Chase wrote:

Shaun Lloyd wrote in post #1061602:

understand the security implications of having your own process!

The cost of starting a Rails app is huge - several seconds of startup
time. You really really don't want to do this from scratch on every
request.

It's a real huge. I did tests locally, cross country and cross
continent.
I love ruby and rails but honest ruby on rails has very serious
performance issues.

That just means you're using it wrong. Rails was *never* intended to be
run as a CGI, it's just a ridiculuous thing to do. Run Rails as a
persistent webserver and proxy to it; or run it under Apache using
Phusion Passenger, which will also run any other Rack-based application.

I installed rails through cpanel installer.
It is running on individual port standard production installation!

I was comparing python-cgi / perl-cgi / ruby-cgi / rails_app

In my work over the last couple of days i have found phusion passenger and have
found performance increase with that setup. But it sort of a mute point from my
perspective.

I'm not trying to use rails i was trying to understand how to use ruby without it!

But having said that i've used a heap of frameworks of the years, it's very very good!

You might get away with running a smaller framework like Sinatra as a
CGI, but it will still have a poor response time. Remember that if you
are using a database, it will need to make a fresh connection to the
database for every request too

Got on to RACK thanks.

Anyway, this is the wrong mailing list for discussing Rails. Rails is
not Ruby, and this is the Ruby mailing list.

Sorta my reason for posting hear in the first place. I wanted more information on
using "ruby" in web architecture and all i could find out about was rails.

Regards,

Brian.

Cheers

···

On 23/05/12 19:36, Brian Candler wrote:

On 22/05/12 03:37, Brian Candler wrote:

Andrew Mcelroy wrote in post #1061808:

> performance issues.

That just means you're using it wrong. Rails was *never* intended to be
run as a CGI, it's just a ridiculuous thing to do. Run Rails as a
persistent webserver and proxy to it; or run it under Apache using
Phusion Passenger, which will also run any other Rack-based application.

At the end of the day, look at what rack is using. CGI.

Rack is an API. The request variables it passes on happen to be similar
to CGI environment variables. Rack invokes your handler's "call" method
for each request. A single process can handle many requests (even
concurrent requests in different threads, if the web server supports
this)

CGI is also an API. However in practice CGI requires a new process to be
started for each request, the parameters to be passed in that process'
environment, the request to be passed on stdin (until EOF) and the
response to be returned on stdout (until EOF). It cannot accept more
than one request per process.

That is, although the CGI spec allows for "system defined" ways of
passing the environment, the only implementation you are likely to find
is as described above. Of course there are things like FastCGI and SCGI
which support persistent processes, but I would consider those not to be
CGI.

···

On Wed, May 23, 2012 at 4:36 AM, Brian Candler <lists@ruby-forum.com> > wrote:

--
Posted via http://www.ruby-forum.com/\.

Shaun Lloyd wrote in post #1061834:

I'm not trying to use rails i was trying to understand how to use ruby
without it!

Ah, I see. Google "ruby microframework". Sinatra is probably the
front-runner; Camping is also worth a look, although its use of
metaprogramming may mess with your head :slight_smile:

···

--
Posted via http://www.ruby-forum.com/\.

How about mod_ruby?
http://modruby.net/en/index.rbx/mod_ruby/whatis.html

Henry

···

On 24/05/2012, at 2:46 AM, Shaun Lloyd <list@lloydie.org> wrote:

Sorta my reason for posting hear in the first place. I wanted more information on
using "ruby" in web architecture and all i could find out about was rails.

I'd say Camping is not that bad, and we have a reasonably good
documentation (so hopefully you won't need to dive into the code).

Just stay away from Camping.goes and don't try to figure out how
routes work – unless you're in a mood for a mind-twister.

The rest will "only" require you understand the entirety of Ruby's
syntax and standard library, including the obscure corners :wink: Reading
Camping's code is – honestly – a great way to learn some obscenely
awful tricks :smiley:

-- Matma Rex

···

2012/5/23 Brian Candler <lists@ruby-forum.com>:

Ah, I see. Google "ruby microframework". Sinatra is probably the
front-runner; Camping is also worth a look, although its use of
metaprogramming may mess with your head :slight_smile:

Henry Maddocks wrote in post #1061869:

How about mod_ruby?
http://modruby.net/en/index.rbx/mod_ruby/whatis.html

Not recommended. For one thing it's unmaintained, and you'll be lucky to
make it work with a modern Apache. For another, all apps share the same
ruby interpreter, and therefore are liable to stomp on each other (e.g.
changes made to core classes in one will affect all others)

I think it's fair to say everybody uses Rack as the middleware layer
now. On top of Rack you can sit frameworks like Rails, Sinatra, Camping,
Ramaze etc. Underneath Rack you can run Mongrel, Thin, Unicorn,
Rainbows!, Zbatery etc and proxy HTTP to them; or you can run Apache and
Phusion Passenger.

I believe there's a Rack handler for fastcgi too, but I doubt it's used
much given the other deployment options listed above.

···

--
Posted via http://www.ruby-forum.com/\.

I don't want any framework. Although i have been looking at rails and am extremely impressed.

I just want to know the "fastest" way to execute ruby code in a web server and display output.
Like a hacking challenge one could think of the problem.

I think compilation will be the way to go.

···

On 24/05/12 02:16, Brian Candler wrote:

Shaun Lloyd wrote in post #1061834:

I'm not trying to use rails i was trying to understand how to use ruby
without it!

Ah, I see. Google "ruby microframework". Sinatra is probably the
front-runner; Camping is also worth a look, although its use of
metaprogramming may mess with your head :slight_smile:

This was in response to the OP's request for ways to execute ruby code in a web server and display output. It was not a recommendation.

Henry

···

On 24/05/2012, at 10:07 AM, Brian Candler wrote:

Henry Maddocks wrote in post #1061869:

How about mod_ruby?
http://modruby.net/en/index.rbx/mod_ruby/whatis.html

Not recommended.

thanks brian, heaps of stuff for me to try :slight_smile:
cgi can work well but i get your points Brian - cheers

Proxy's are without doubt the most mis-understood element of our network today.

But i need multi-threaded parrallel exec and async non-blocking io so proxy need to
layer above above rather than part of platform (hope i made some sense).

I looking into compilation today, Rubyspec have some really cool stuff !
Getting that code into apache module is the tricky bit but.

Thought i might have a look a that patterns in phusion as well see if some refactoring
can be done.

Brian i was wondering what platform you is your "favourite" at least for web distributed code.

Thanks very much.

···

On 24/05/12 08:07, Brian Candler wrote:

Henry Maddocks wrote in post #1061869:

How about mod_ruby?
http://modruby.net/en/index.rbx/mod_ruby/whatis.html

Not recommended. For one thing it's unmaintained, and you'll be lucky to
make it work with a modern Apache. For another, all apps share the same
ruby interpreter, and therefore are liable to stomp on each other (e.g.
changes made to core classes in one will affect all others)

I think it's fair to say everybody uses Rack as the middleware layer
now. On top of Rack you can sit frameworks like Rails, Sinatra, Camping,
Ramaze etc. Underneath Rack you can run Mongrel, Thin, Unicorn,
Rainbows!, Zbatery etc and proxy HTTP to them; or you can run Apache and
Phusion Passenger.

I believe there's a Rack handler for fastcgi too, but I doubt it's used
much given the other deployment options listed above.

Shaun Lloyd wrote in post #1061905:

I don't want any framework. Although i have been looking at rails and am
extremely impressed.

I just want to know the "fastest" way to execute ruby code in a web
server and display output.
Like a hacking challenge one could think of the problem.

You can write applications which talk to Rack directly, and that will be
the fastest way to generate a response. I'm sure there's a "hello world"
Rack example.

If you have this performance requirement in a real-world application,
you can still use Rails. There is "Rails Metal" which lets you connect
certain actions directly to Rack.

···

--
Posted via http://www.ruby-forum.com/\.

All good henry, i appreciate it. You wouldn't believe how quick you can port modruby to execute bytecode precompiled. No release for years but it was cool to see if my idea at least could work.

thanks mate.

···

On 24/05/12 12:53, Henry Maddocks wrote:

On 24/05/2012, at 10:07 AM, Brian Candler wrote:

Henry Maddocks wrote in post #1061869:

How about mod_ruby?
http://modruby.net/en/index.rbx/mod_ruby/whatis.html

Not recommended.

This was in response to the OP's request for ways to execute ruby code in a web server and display output. It was not a recommendation.

Henry