Using Thin Instead Of Mongrel 18

Posted by jeff Sunday, April 27, 2008 17:13:00 GMT

I’m learning how to switch from mongrel to thin. If you’ve never heard about thin, you can try to read the documentation, learn about the new-cool-kid-on-the-block Rack specification, or just take my word for it: thin is better than mongrel, so just use it, ok?

It can be intimidating to try something that’s got buzz about it but you don’t really know how to get started and no one seems to really be stopping to explain it in English. So if you’re still using script/server to start mongrel or webrick, and are interested in something new, then read on.

The main reason people switch from mongrel to thin is for improved performance on their servers. But for me to learn something new, I have to first dogfood it in my development environment first. That’s what I’ll be covering in this article, and in an article coming soon to a blog near you I’ll explain how to replace your mongrel configurations with a thin configuration instead.

One note: thin is currently best suited for Mac and Linux people. I’ve used it on Windows as simple script\server replacement, but on Windows background (“daemon”) mode isn’t supported, nor is clustering, so Mongrel is still my choice on Windows boxes.

gem install thin

It won’t wreck your computer. Honest. Just do it.

Using thin to replace script/server

script/server doesn’t know to startup thin instead of mongrel (as of Rails 2.0.2). So instead, you just go to your RAILS_ROOT and do this:

myapp$ thin start

You’ll see it start up on port 3000 using the “Rails adapter.” (Turns out thin can support a variety of Ruby frameworks, not just Rails).

Need to use a different port, say, 4000?

myapp$ thin start -p 4000

On Mac/Linux, you could use script/server -d. With thin, you also use -d:

myapp$ thin start -d

To stop thin that’s been start with -d, you just, um, stop it:

myapp$ thin stop

By default, thin will create .pid files in your applications /tmp folder. If you prefer to keep your .pid files in the log directory like Mongrel did, you can specify that:

myapp$ thin start --pid log/thin.pid

Just be sure to stop it the same way:

myapp$ thin stop --pid log/thin.pid

More Options

Do a thin -h to see all the possible options. I’ll highlight just a couple more.

To specify your Rails environment, use -e just like with Mongrel:

myapp$ thin start -e production

Stopping and restarting the server is easier than it was with mongrel:

myapp$ thin restart

(Remember to also use your -e, -d,—pid, etc. options here as well if you need to.)

Next Time

Next time we’ll talk about how to setup a cluster of thin instances on your server, instead of using mongrel_cluster.

And I’d also like to be able to answer any other questions about script/server, mongrel, thin, nginx, apache, or why the Blackhawks missed the playoffs again this year. Leave a comment with your suggestions and questions if you’re so inclined.

Comments

Leave a response

  1. macournoyer   April 27, 2008 @ 06:11 PM

    Hey thx for the great tutorial jeff!

    "thin restart" does remember your options, so you don't have to specify -d, -e, etc, only --pid is required, so it should be even easier ;)

    If you have any problem using Thin, be sure to join the Google group: http://groups.google.com/group/thin-ruby/topics, we have a very active community.

  2. Brian   April 27, 2008 @ 07:28 PM

    Exactly why did the Blackhawks miss the playoffs again?

  3. BradfordW   April 27, 2008 @ 08:19 PM

    I wouldn't worry too much about the Blackhawk's missing this year. You'll have a much stronger team next season. Being a Detroit native living in Nashville, I'm glad to see the under-appreciated Red Wings taking it to the rest of the league. It will be a vicious central division next year, it'll be great to watch.

    Anyway, onto more nerdier things...you should remind people that thin is an event-driven webserver and that it's going to choke and die on any long-running processes if you're serving up lots of requests. This is due to the blocking involved with events (this happens in evented mongrel as well).

    I'd like to just point out that I do use thin on a few sites and it is absolutely incredible how fast it serves up my pages. However for another site (practice management for doctors) I do have some long-winded requests and mongrel handles them much faster.

    Long story short thin is great, just be careful if you have long responses. Keep up the great site guys. GO WINGS!

  4. Ethan   April 27, 2008 @ 09:46 PM

    Thin sounds great, but why not just use modrails and save hours of effort? As far as I know, modrails has no issues with "choking and dying" on long-running requests.

    On the other hand if you're using Merb or Sinatra mod_rails won't work, so you'd need something like thin.

  5. nap   April 27, 2008 @ 10:47 PM

    /me repeats what BradfordW said. Except for the part about hockey, of which I know nothing.

  6. Joe   April 27, 2008 @ 10:54 PM

    On Mac Leopard:

    sudo gem install thin Building native extensions. This could take a while... .. Successfully installed thin-0.8.1 4 gems installed ....

    ~/Dev/my/rails/root$ thin start -bash: thin: command not found

    Any ideas?

  7. Jeff   April 28, 2008 @ 04:07 PM

    @macournoyer: Thanks for the tip about the restart command - good to know. I have more questions for you but I'll head over to the google group for those.

    @BradfordW: First off, any comment from now on that includes GO WINGS will be automatically deleted! :-) And don't forget we actually beat you guys a few times this year, which I think hasn't happened since, oh, 1869 or something like that. Excellent point about handling long requests with thin. I am going to try to learn more about that.

    @Ethan: Good question, and I think Apache/mod_rails can be a very good choice, but I'm using nginx these days.

    @Joe: Any luck yet? I'm not sure why the command can't be found. Perhaps your path isn't set correctly? Try doing a gem env to see where your gems are being stored.

  8. Sebastian   April 28, 2008 @ 07:59 PM

    Did you measure difference in performance between mongrel and thin?

  9. BradfordW   April 28, 2008 @ 08:31 PM

    @Jeff - Don't hate! Just as Detroit will (possibly) begin winding down, your organization is really on the upswing. They just need to get a goaltender that can give them the mileage during the regular season.

    In regard to the long requests - thin actually has a mechanism which will allow you to defer those slower requests in a threaded model. So you don't miss a beat! I need to get to a meeting, but will post the link shortly.

  10. BradfordW   April 28, 2008 @ 09:11 PM

    My mistake I believe it's merb-centric...maybe with Ezra's patch for Rack/Rails it would be possible.

  11. Luigi Montanez   April 30, 2008 @ 04:40 AM

    Here’s a link to a presentation I did on Thin earlier this month and some resources:

    http://salesforceonrails.com/2008/presentation-on-thin

    Hopefully someone finds it useful!

  12. austin_web_developer   May 01, 2008 @ 02:11 AM

    @Ethan Because Mod_rails doesn’t work on windows?

  13. a   May 01, 2008 @ 02:14 AM

    @Sebastian Here’s a benchmark comparison of mod_rails, thin and mongrel. Mongrel seems to pip Thin … still.

  14. austin_web_developer   May 01, 2008 @ 02:17 AM

    It would be cool if someone could help me figure out how to get thin to be an actual replacement for script/server the way mongrel replaces webrick for that command after its installed.

    I got halfway through making it work and gave up.

  15. Michael Leung   May 05, 2008 @ 06:13 PM

    Thin is really cool, and fast, but doesn’t work well if you have long running actions. So if you have an action that is blocking, thin will be infinitely slower than mongrel. I haven’t read all the comments so I’m hoping no one already mentioned this.

    Also, Thin seems to have some issues with merb. Specifically doing a render_then_call.

    I’m using it on my merb blog now, and it’s definitely faster than mongrel, but all my actions return back pretty much instantaneously.

    Just my $0.02.

  16. kino   May 24, 2008 @ 01:09 AM

    Our faculties (and we can deduce that this is the case) are the clue to the discovery of the objects in space and time.

  17. Ellroy   May 30, 2008 @ 11:16 PM

    Our a priori knowledge excludes the possibility of natural causes.

  18. aspire cb   June 06, 2008 @ 11:11 PM

    Nice Site! http://google.com

Comment


(won't be published)