Why would you start multiple thin servers? [closed]
Asked Answered
G

1

6

In the Thin website: http://code.macournoyer.com/thin/usage/ it says that you can start multiple servers using:

thin start --servers 3
  1. Why would you need to do this?
  2. Is each server assigned a different port or something?
Gigot answered 25/11, 2012 at 7:6 Comment(0)
M
7
  1. You would start more than one instante of thin if you may have concurrent requests to process. To manage concurrent requests (Simultaneous connections) you need a cluster of "thin".

  2. Yes, you can easily see this:

let's try a single-server thin

 thin start -R fart.ru
 Thin web server (v1.5.0 codename Knife)
 Maximum connections set to 1024
 Listening on 0.0.0.0:3000, CTRL+C to stop

check:

 netstat -an | grep 300
 tcp4       0      0  *.3000                 *.*                    LISTEN     

ok, we have a thin listening on one port.

now let's try a --servers 3

 thin start -R fart.ru --servers 3
 Starting server on 0.0.0.0:3000 ... 
 Starting server on 0.0.0.0:3001 ... 
 Starting server on 0.0.0.0:3002 ... 

check:

 netstat -an | grep 300
 tcp4       0      0  *.3002                 *.*                    LISTEN     
 tcp4       0      0  *.3001                 *.*                    LISTEN     
 tcp4       0      0  *.3000                 *.*                    LISTEN    

voilà you have 3 port listening.

 ps -ef | grep thin 

reports 3 processes running, each one can manage a concurrent request.

Ultimately to concurrently process requests you have to start a cluster of thin and reverse proxy your virtual host then load balance the request on the various thin you've started.

This blogpost can make the point: Scaling Rails with Apache 2, mod_proxy_balancer and Thin Clusters

Moulton answered 26/11, 2012 at 19:45 Comment(3)
For how many requests per second do you need more thin servers?Diopside
quoting amberbit.com/blog/2014/9/9/ruby-the-bad-parts The performance of multithreaded applications is still limited, though. Ruby interpreter uses mechanism called GIL (Global Interpreter Lock) which allows only one thread to execute at a time, even if ran on multi-processor system i.e. if you have quad core system may be resources are better utilized. Anyway load and performance testing is recommended and useful to understand how this can or not apply to your application and runtime environment.Moulton
This information about the GIL is wrong. The --servers parameters will start up several ruby processes, not threads. This is an important distinction, because the GIL can only affect threads within the same process, not separate processes. By that chain of logic, you wouldn't be able to run completely different ruby programs on the same machine, because their GIL's would affect each other.Muttonhead

© 2022 - 2024 — McMap. All rights reserved.