Trong trang web Thin: http://code.macournoyer.com/thin/usage/ nó nói rằng bạn có thể bắt đầu nhiều máy chủ sử dụng:Tại sao bạn sẽ bắt đầu nhiều máy chủ mỏng?
thin start --servers 3
Bạn sẽ bắt đầu nhiều hơn một instante của mỏng nếu bạn có thể có yêu cầu đồng thời để xử lý. Để quản lý các yêu cầu đồng thời (các kết nối đồng thời), bạn cần một cụm "mỏng".
Vâng, bạn có thể dễ dàng thấy điều này:
chúng ta hãy thử một single-server mỏng
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
kiểm tra:
netstat -an | grep 300
tcp4 0 0 *.3000 *.* LISTEN
ok, chúng ta có một mỏng lắng nghe trên một cổng.
bây giờ hãy thử một tấm séc --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 ...
:
netstat -an | grep 300
tcp4 0 0 *.3002 *.* LISTEN
tcp4 0 0 *.3001 *.* LISTEN
tcp4 0 0 *.3000 *.* LISTEN
thì đấy bạn có 3 cổng lắng nghe.
ps -ef | grep thin
báo cáo 3 quy trình đang chạy, mỗi quy trình có thể quản lý yêu cầu đồng thời.
Cuối cùng để đồng thời xử lý các yêu cầu, bạn phải bắt đầu một nhóm proxy mỏng và ngược lại máy chủ ảo của bạn sau đó tải cân bằng yêu cầu trên các loại mỏng khác nhau mà bạn đã bắt đầu.
Bài đăng trên blog này có thể làm cho điểm: Scaling Rails with Apache 2, mod_proxy_balancer and Thin Clusters
Đối với số lượng yêu cầu mỗi giây bạn cần máy chủ mỏng hơn? –
trích dẫn http://www.amberbit.com/blog/2014/9/9/ruby-the-bad-parts/ Hiệu suất của các ứng dụng đa luồng vẫn còn hạn chế. Trình thông dịch Ruby sử dụng cơ chế GIL (Global Interpreter Lock) cho phép chỉ có một luồng để thực hiện tại một thời điểm, ngay cả khi chạy trên hệ thống đa bộ xử lý tức là nếu bạn có hệ thống lõi tứ có thể được sử dụng tốt hơn. Việc kiểm tra tải và hiệu năng bất kỳ được khuyến nghị và hữu ích để hiểu cách thức này có thể hoặc không áp dụng cho môi trường ứng dụng và thời gian chạy của bạn. –
................. Cảm ơn bạn –