addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupsimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1outlookpersonJoin Group on CardStartprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [ruby-81] stack: Passenger vs Unicorn

From: Noah
Sent on: Thursday, November 8, 2012 9:19 PM
Yes, Unicorn is designed to use a limited number of workers.  Lots of long-running requests can quickly tie up your whole worker pool, and Unicorn has built-in timeouts which can kill the connection before it's done if your request runs *too* long.

Passenger works the same way, and has the same property.

You can reverse-proxy for either one with NGinX, which can buffer upload objects before they get to Rails if you install the right plugin -- uploads are the most common huge, long-running requests, and raw Passenger or Unicorn can do badly with them.  I'm sure there's something similar for Apache.

If you're going to have a lot of connections but not a lot of load on each one, consider using Thin, which does a great job at this.  Thin will also handle EventMachine if you're doing a huge amount of low-load long-running requests and need to rearchitect your Ruby process for that.  Standard frameworks (Rails, Sinatra) aren't great for lots of concurrency but very little actual work done.  That's more the Node.js/EventMachine use case.

From: Adrien <[address removed]>
To: [address removed]
Sent: Thursday, November 8,[masked]:27 PM
Subject: Re: [ruby-81] stack: Passenger vs Unicorn

>> ... I use Passenger at home and Unicorn at work, and I like them both.

Apparently, one of the issues with Unicorn is that it is designed to respond to fast connections, and will supposedly experience problems with slow/high latency requests. Some people on the Ruby-6 list expressed a preference for Heroku's "routing mesh", claiming it dynamically deals with different connection speeds. I'm curious about how to deal with such issues when using a standard *nix server with Apache; I've been using Unicorn and so far haven't experienced problems, but have yet to set up a test with a slow connection case.

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Adrien ([address removed]) from The East Bay Ruby Meetup Group.
To learn more about Adrien, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy