Ruby a good choice for CGI?

Ruby
21

On Wednesday 25 November 2009 04:17:02 pm Marnen Laibow-Koser wrote:

David M. wrote:

that it’s actually somewhat production-ready

Strike the “somewhat”.

There’s actually some debate about whether or not it can scale. Not
something
I’m particularly interested in at the moment, though.

and it has something to do with Ruby Enterprise
Edition.

It’s written by the same people, and I believe it can take advantage of
some Ruby EE optimizations. But you can use it just as well with MRI
(although I’m not sure why you would – EE is much faster).

Is there an EE for 1.9 yet? Depending on your app, 1.9.1 may be much
faster.

I don’t really see the case for Passenger

Incredible ease of configuration, EE optimizations. AFAIK, Passenger
has no serious competition on either of these points.

Capistrano is pretty easy, but that’s my opinion. But if I use Ruby EE,
Unicorn does the exact same thing, while remaining much more loosely
coupled
from the webserver.

over these, other than
simplicity of
deployment.

Not app deployment so much as configuration.

Configuration is part of deployment. Any serious shop really should have
a
task set up for building the entire stack, including the load balancer.

Am I missing anything?

You’re missing just about everything. :slight_smile: Personally, I’m not sure what
the case against Passenger is, unless you’re using Windows or JRuby.

Complexity. Plus, it used to require Apache…

I suppose a bigger case against it is that it seems like Unicorn can do
all of
that, but be far more static-server-agnostic – I can run it by itself
on a
port, or with nginx via a Unix socket.

Didn’t 37signals switch to Passenger some time ago?

Yeah, that doesn’t really impress me. The important question is why they
chose
it – I linked to an article, not just about Github using nginx+unicorn,
but
why they did, and why that looks to me like a good idea.

22

On Wednesday 25 November 2009 05:21:52 pm Judson L. wrote:

On Wed, Nov 25, 2009 at 2:17 PM, Brian C. [email protected] wrote:

Well for one thing, many sites are a mixture of static assets and
dynamic content. It’s much more efficient to serve the static assets
from a webserver tuned for serving this sort of content, rather than
serving your entire site from a ruby server.

Right, that’s the reason most of the older setups called for something
like
Apache or nginx, proxied to something like mongrel.

I wanted to amplify with use cases that run more than one app on the same
server. My experience is that getting two Rails apps to play nicely in
the same environment is a pain.

Huh. I don’t know that I’d call it “easy”, but I was able to solve this
by
running those apps as separate user accounts, separate databases and
MySQL
passwords, etc. Once I had a task set up for it, the biggest irritation
was
managing ports. With Unix sockets and a master/slave setup like Unicorn,
that
goes away.

With Passenger I can run Rails alongside PHP, and serve static
content far more efficiently. (nginx is on my saw-sharpening list…)

I definitely ran PHP when I was doing the above. Remember, with the
traditional setup, each mongrel is a separate webserver to proxy to.
It’s not
hard to proxy to another server running PHP, if you have to.

But basically what I’m hearing is that I’m right – ease of
setup/deployment
is the win for Passenger.

One possible point against passenger: How easy is it to run each
individual
Rails app as a separate user?

23

David M. wrote:
[…]

One possible point against passenger: How easy is it to run each
individual
Rails app as a separate user?

Trivial. IIRC, each Passenger app runs as whichever user owns (I think)
it’s environment.rb file.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

24

David M. wrote:

But basically what I’m hearing is that I’m right – ease of
setup/deployment
is the win for Passenger.

and ongoing management and tuning - it handles dynamic pools of
processes for you

and RAM usage - when combined with REE, the forking of your app means
much of the ruby object space is shared, so more performance for the
same $$

and it has excellent documentation

One possible point against passenger: How easy is it to run each
individual
Rails app as a separate user?

It does this by default.
http://www.modrails.com/documentation/Users guide
Apache.html#user_switching

25

On Thursday 26 November 2009 11:03:41 am Nick Dr wrote:

=

That sounds tailor-made for Sinatra. However, you should learn something
about
REST, first – are you sure POST is appropriate?

Ok I tried sinatra. It seems like it fires up webrick on port 4567, so I
take it there’s some config file I need to mess with, or my hosting
provider deals with so it’ll run on Apache instead?

Well, yes and no. Sinatra by default fires up on 4567 using supported
servers
(webrick, mongrel, etc). However, it is a Rack app, and you can
configure a
rackup file to load your app via anything that does Rack.

So they could use Apache or Nginx (via Passenger), or they could use any
of
the standalone Ruby servers behind Apache or Nginx, or they could have
some
custom setup. The point is that Rack is the standard modern way of
connecting
a webserver to a Ruby web app/framework.

Also, I can hit my sinatra ruby script from my browser, but when I tried
to hit it from a jQuery AJAX request, I get nothing back and the sinatra
console says that it was an OPTIONS request instead of the GET request
it reports when firefox asks for the page.

Quick question: What browser? I had a similar issue with a Chromium
build.

One possible test: Run something like netcat locally, so you capture the
raw
traffic. I very much doubt Sinatra is wrong – I bet your browser is
(erroneously) sending OPTIONS instead of GET.

FastCGI is obsolete, so scratch that.

The host I was considering, HostingRails, says they’ll do a FastCGI
deployment for me.

Do they also support Rack?

Are you sure FastCGI isn’t a good option for this?

No, but I’m sure it’s a weird hack, I doubt it really performs well (or
people
wouldn’t have started using Mongrel in the first place), and I wouldn’t
trust
a host which only supported FastCGI as an option.

Check that they’ll run an arbitrary Rack app.

Passenger and mod_ruby are essentially the same thing, IIRC. But my
understanding is that Passenger works with Rack, which doesn’t feel at
all
like CGI. So these might be deployment options, but they have nothing to
do
with how you write and develop your app.

So I can just use the Sinatra lib to route the request, deal with
cookies and sessions, and then hand it to my hosting provider and
they’ll set it up properly?

Hopefully. That’s the point of Rack, anyway.

26

David M. wrote:

and ongoing management and tuning - it handles dynamic pools of
processes for you

So does Unicorn, or maybe I’m not understanding.

http://unicorn.bogomips.org/

From reading this, and the FAQ/Philosophy, it sounds like you configure
it with a static sized pool. They advise you to spit out the request
as quickly as possible into a buffering reverse proxy, so you can get
onto handling the next request - then you scale your app to the
available CPU resources, rather than to the number of concurrent
clients.

That’s a reasonable approach for many apps, whatever server you deploy
them under. OTOH that won’t work for apps which return large or infinite
streams.

Also, as far as I can tell, to use Unicorn properly requires you to use
nginx (at least, I don’t know if apache can proxy to a unix domain
socket, and the documentation doesn’t seem to mention apache)

On the plus side: you do get very fine-grained control of the
deployment.

Anyway, it’s always good to have alternatives. Projects come and
projects go, and it’s comforting to know there are things to migrate to.

27

On Friday 27 November 2009 02:48:50 am Brian C. wrote:

David M. wrote:

But basically what I’m hearing is that I’m right – ease of
setup/deployment
is the win for Passenger.

and ongoing management and tuning - it handles dynamic pools of
processes for you

So does Unicorn, or maybe I’m not understanding.

and RAM usage - when combined with REE, the forking of your app means
much of the ruby object space is shared, so more performance for the
same $$

Unicorn does this, too.

and it has excellent documentation

That’s a win, I guess.

I don’t mean to start a big debate here, nor am I wanting to just shout
“I
heart Unicorn”, I’m actually trying to understand pros and cons. I’m
still
seeing “ease of use” in some form as the big win for Passenger.

28

On Friday 27 November 2009 04:40:55 am Brian C. wrote:

David M. wrote:

and ongoing management and tuning - it handles dynamic pools of
processes for you

So does Unicorn, or maybe I’m not understanding.

http://unicorn.bogomips.org/

From reading this, and the FAQ/Philosophy, it sounds like you configure
it with a static sized pool.

Ah. Thanks for the clarification.

That’s a reasonable approach for many apps, whatever server you deploy
them under. OTOH that won’t work for apps which return large or infinite
streams.

Yes, I think that’s what Rainbows is for. But I haven’t looked into that
in
much depth. From the readme: “We aim to support as many concurrency
models as
we can because they all suck; differently.”

Also, as far as I can tell, to use Unicorn properly requires you to use
nginx (at least, I don’t know if apache can proxy to a unix domain
socket, and the documentation doesn’t seem to mention apache)

It can also listen via TCP.

On the plus side: you do get very fine-grained control of the
deployment.

Yes, that was the big win for me.