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.
Shaun L. 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.
On 21/05/12 21:33, Matthew R Chase wrote:
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 22/05/12 03:37, Brian C. wrote:
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.
Shaun L. 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.
On Wed, May 23, 2012 at 4:36 AM, Brian C. [email protected]
wrote:
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
Shaun L. wrote in post #1061602:
On 22/05/12 03:37, Brian C. wrote:
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 23/05/12 19:36, Brian C. wrote:
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
Andrew Mcelroy wrote in post #1061808:
On Wed, May 23, 2012 at 4:36 AM, Brian C. [email protected]
wrote:
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 22/05/12 20:48, Matthew R Chase wrote:
Shaun L. 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.
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 
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.
2012/5/23 Brian C. [email protected]:
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 
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 
Reading
Camping’s code is – honestly – a great way to learn some obscenely
awful tricks 
– Matma R.
Shaun L. 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
On 24/05/2012, at 2:46 AM, Shaun L. [email protected] 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.
How about mod_ruby?
http://modruby.net/en/index.rbx/mod_ruby/whatis.html
Henry
Henry M. 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.
On 24/05/12 02:16, Brian C. wrote:
Shaun L. 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
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/2012, at 10:07 AM, Brian C. wrote:
Henry M. 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
On 24/05/12 12:53, Henry M. wrote:
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 08:07, Brian C. wrote:
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.
thanks brian, heaps of stuff for me to try
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.
Shaun L. wrote in post #1061910:
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).
Proxy is a separate layer, yes. Proxy can handle multiple concurrent
requests from different clients and direct them to different back-end
servers, yes.
I looking into compilation today, Rubyspec have some really cool stuff !
Getting that code into apache module is the tricky bit but.
You don’t want to be putting code into Apache, for the reasons outlined
before (mod_ruby).
Brian i was wondering what platform you is your “favourite” at least for
web distributed code.
Phusion Passenger is probably the easiest to get up and running, and
includes useful features like dynamic pools of workers.
If you need the fastest possible roundtrip time you could try proxying
to one of the ruby HTTP servers (one of unicorn/rainbows!/thin was
optimised for short-lived queries, I can’t remember which it was)