Thin vs Unicorn trên Heroku

Question

Chỉ muốn nhận ý kiến ​​của mọi người về việc sử dụng Unicorn vs Thin làm máy chủ đường ray. Hầu hết các bài báo/điểm chuẩn mà tôi tìm thấy trực tuyến dường như rất không đầy đủ, vì vậy sẽ rất hay khi có một nơi tập trung để thảo luận về nó.

Unicron là máy chủ đa quy trình, trong khi mỏng là máy chủ dựa trên sự kiện/không chặn. Các máy chủ dựa trên sự kiện rất tuyệt ... nếu mã của bạn là không đồng bộ/không chặn - đường ray vanilla đang chặn. Vì vậy, trừ khi bạn sử dụng các thư viện không bị chặn, tôi thực sự không thấy lợi thế của việc sử dụng Thin. Thậm chí tệ hơn, trong một máy chủ không chặn, nếu vòng lặp i/o của bạn đang chặn, bạn sẽ chặn toàn bộ vòng lặp và không thể xử lý thêm bất kỳ yêu cầu nào cho đến khi cuộc gọi chặn trả về. Chặn các thư viện sẽ làm chậm quá trình làm chậm!

Tại sao Heroku chọn Thin làm máy chủ mặc định của họ (cho gỗ tuyết tùng)? Họ là những người thông minh, vì vậy tôi chắc chắn họ có lý do.

Dưới đây là một liên kết gợi ý thay thế Thin bằng 4 công nhân Unicorn - điều này có ý nghĩa hoàn hảo với tôi. 4 Unicron workers on Heroku

Answer 1

Mỏng dễ cấu hình - không tối ưu, nhưng nó chỉ hoạt động trong môi trường Heroku.

Unicorn có thể hiệu quả hơn nhưng cần phải được định cấu hình: Có bao nhiêu công nhân? Tải trước ứng dụng? Bạn chọn gì

Tôi đã phát hành ứng dụng Unicorn Heroku với công nhân được đặt thành 3, 5 và 8 - chỉ dựa trên mức độ lớn của mỗi ứng dụng - số lượng mã, số lượng bộ nhớ được sử dụng và số lượng lưu lượng truy cập bạn chọn và bạn cần phải theo dõi theo thời gian để đảm bảo bạn có được số lượng phù hợp và ứng dụng của bạn không hết bộ nhớ.

Preload giả - điều này sẽ làm cho ứng dụng của bạn bắt đầu chậm hơn, nhưng khi Unicorn khởi động lại một nhân viên, đây là 'an toàn' với các kết nối mạng (memcache, postgres, Mongo vv)

Preload đúng - đây là tốt hơn, nhưng bạn cần phải xử lý các kết nối lại máy chủ một cách chính xác trong mã pre và post fork.

Mỏng không có vấn đề nào trong số này, nhưng bạn chỉ nhận được quá trình thực thi.

Tóm tắt: Thật khó cấu hình Unicorn ra khỏi hộp để hoạt động tốt (hoặc ở tất cả) cho mọi người, trong khi Thin chỉ có thể làm việc để mọi người chạy với ít yêu cầu hỗ trợ hơn.

Answer 2

Heroku không sử dụng định tuyến thông minh - nó sẽ chỉ định ngẫu nhiên công việc cho dynos bất kể dyno có bận không. Vì vậy, nếu dyno của bạn không thể xử lý nhiều công việc cùng một lúc, bạn sẽ nhận được độ trễ (có lẽ độ trễ lớn) ngay cả khi bạn đang trả tiền cho rất nhiều dynos khác là miễn phí. "Đúng vậy - nếu ứng dụng của bạn cần 80 dynos với một bộ định tuyến thông minh, nó cần 4.000 bộ định tuyến ngẫu nhiên." http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics

Heroku nói rằng họ đang làm việc này và kế hoạch của họ là dễ sử dụng Unicorn hơn. Về cơ bản họ nói "Rất tiếc, chúng tôi đã không nhận thấy rằng đây là một vấn đề trong vài năm ... và bây giờ chúng ta nhìn, đó chắc chắn là một vấn đề đối với Thin ... vì vậy tôi đoán bạn cần sử dụng một chương trình khác với chúng tôi đã đẩy tất cả thời gian này. " http://news.rapgenius.com/Jesper-joergensen-routing-performance-update-lyrics

Từ lời giải thích chính thức Heroku (liên kết thứ hai ở trên):. "Rails, trên thực tế, chưa đáng tin cậy hỗ trợ xử lý yêu cầu đồng thời này lá Rails nhà phát triển không thể thúc đẩy khả năng đồng thời thêm được cung cấp bởi các đống Cedar, trừ khi họ chuyển sang một máy chủ web đồng thời như Puma hoặc Unicorn.

Các ứng dụng Rails được triển khai tới Cedar bằng Thin có thể nhanh chóng kết thúc với các vấn đề xếp hàng theo yêu cầu. Bởi vì các bộ định tuyến Cedar không còn làm bất kỳ xếp hàng thay mặt cho các ứng dụng, yêu cầu xếp hàng tại dyno phải chờ đợi cho đến khi quá trình Rails duy nhất hoạt động theo cách của mình thông qua hàng đợi. Nhiều khách hàng đã gặp vấn đề này và chúng tôi không thực hiện hành động và cung cấp cho họ cách tiếp cận tốt hơn để triển khai các ứng dụng Rails trên Cedar. "

Quan tâm nữa là các công cụ hiệu suất của họ, bao gồm New Relic, chưa được báo cáo chi tiêu trong hàng đợi Dyno. http://news.rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

Oops.

Answer 3

Gần đây (chỉ một vài tháng trước) folks đằng sau Phusion Passenger thêm hỗ trợ cho Heroku. Chắc chắn đây là một sự thay thế bạn nên thử và xem nếu phù hợp với nhu cầu của bạn.

I s rực nhanh ngay cả với 1 dyno và thả trong thời gian đáp ứng là sờ thấy. Một đơn giản Passenger Ruby Heroku Demo được lưu trữ trên github.

Những lợi ích chính mà Hành khách trên tuyên bố Heroku là:

• tăng tốc tài sản tĩnh thông qua Nginx - Đừng để ứng dụng của Ruby của bạn phục vụ tài sản tĩnh, chúng ta hãy Nginx làm điều đó cho bạn và giảm tải ứng dụng của bạn cho các nhiệm vụ thực sự quan trọng. Nginx sẽ làm tốt hơn nhiều.

• Nhiều công nhân xử lý - Thay vì chạy chỉ có một nhân viên trên một Dyno, Phusion tải hành khách chạy nhiều lao động trên một Dyno duy nhất, do đó việc sử dụng nguồn lực để phát huy tối đa của nó và đem lại cho bạn nổ hơn cho buck. Cách tiếp cận này tương tự như của Unicorn. Nhưng không giống như Unicorn, Phusion Passenger tự động quy mô số lượng quy trình công nhân dựa trên lưu lượng truy cập hiện tại, do đó giải phóng tài nguyên khi không cần thiết.

• Tối ưu hóa bộ nhớ - Phusion Hành khách sử dụng ít bộ nhớ hơn Thin và Unicorn. Nó cũng hỗ trợ bộ nhớ ảo copy-on-write kết hợp với tải trước mã, do đó làm cho ứng dụng của bạn sử dụng ít bộ nhớ hơn khi chạy trên Ruby 2.0.

• Yêu cầu/phản hồi đệm - Yêu cầu bộ đệm Nginx bao gồm và phản hồi, do đó bảo vệ ứng dụng của bạn khỏi khách hàng chậm (ví dụ: thiết bị di động trên mạng di động) và cải thiện hiệu suất.

• Thu gom rác ngoài băng - Bộ thu gom rác của Ruby chậm, nhưng tại sao lại làm phiền khách truy cập của bạn với thời gian phản hồi dài? Sửa lỗi này bằng cách chạy bộ sưu tập rác bên ngoài chu kỳ yêu cầu-đáp ứng bình thường! Khái niệm này, được Unicorn giới thiệu lần đầu tiên, đã được cải thiện khi: Phusion Passenger đảm bảo rằng chỉ có một yêu cầu đồng thời đang chạy bộ sưu tập rác ngoài băng, do đó loại bỏ tất cả các vấn đề của bộ sưu tập rác ngoài băng của Unicorn.

• Hỗ trợ JRuby - Unicorn là lựa chọn tốt hơn so với Mỏng nhưng không hỗ trợ JRuby. Phusion hành khách nào.

Hy vọng điều này sẽ hữu ích.