Webrick làm máy chủ sản xuất so với Thin hay Unicorn?

117

Có vẻ như việc bạn không được sử dụng Webrick làm máy chủ sản xuất là điều hiển nhiên, nhưng tôi thực sự không thể tìm thấy bất kỳ nơi nào đề cập đến lý do. Sự đồng thuận dường như là: "Webrick có thể phát triển, nhưng Thin hoặc Unicorn là sự lựa chọn để sản xuất."

Tôi đã tìm kiếm trang chủ của máy chủ Thin và nó nói về yêu cầu / giây nhưng tôi không thực sự hiểu biểu đồ vì không có chú thích.

Bất cứ ai có thể cho tôi biết tại sao tôi nên sử dụng Thin hoặc Unicorn so với Webrick? Ngoài ra, có lợi ích gì khi sử dụng Webrick để phát triển không? Tôi đã sử dụng Webrick kể từ khi nó đi kèm với đường ray, và tôi nghĩ phải có lý do tại sao nó lại là mặc định.

Nhân tiện, tôi đang sử dụng Heroku.

— Vlad
nguồn

Nó chậm khi so sánh với những người khác như Mongrel.

— ngày

38

Ken, tôi thực sự không đặt câu hỏi này để tranh luận bất cứ điều gì. Tôi thực sự muốn biết câu trả lời bởi vì tôi không thể tìm thấy số liệu thống kê thực sự ở bất cứ đâu, khi mọi người đều coi Webrick là thấp hơn. Tôi không liên kết với bất kỳ bên nào trong số đó và các cuộc tranh luận mà bạn đã đề cập là những câu hỏi tôi đang hỏi vì tò mò thực sự. Làm thế nào tôi có thể diễn đạt lại câu hỏi để nó không giống như vậy?

— Vlad

24

Đây là một câu hỏi hay.

— justingordon 13/12/12

29

Những câu hỏi như thế này KHÔNG nên đóng lại. Chúng hữu ích và hữu ích. Tất cả cảnh sát nội dung tự bổ nhiệm nên lùi lại.

— Ken Smith

22

Tôi tìm thấy điều này bằng googling "Tại sao không sử dụng WEBrick trong sản xuất?" bởi vì đó là một câu hỏi tôi muốn được trả lời. Tôi không có ý định sử dụng WEBrick trong sản xuất, nhưng tôi thấy thật khó chịu khi mọi người nói, "Rõ ràng là vì nó không dành cho Sản xuất®." Nó thực sự không quá rõ ràng — nếu có, mọi người sẽ không nghiên cứu câu hỏi trước khi cuối cùng hỏi trên StackOverflow, như @Vlad cho biết anh ta đã làm. Câu trả lời được chấp nhận là hữu ích; ít nhất chỉ ra một số tính năng còn thiếu. Theo cách tiếp tục, khăng khăng rằng một câu hỏi được đóng lại vì bạn cho rằng đó là cuộc tranh luận mà không đưa ra câu trả lời của riêng bạn là không hữu ích.

— Justin Force

42

Một vài lý do quan trọng

nó được viết bằng Ruby (xem http://github.com/ruby/ruby/tree/trunk/lib/webrick )
Đã chỉnh sửa nó không có nhiều tính năng mà một trang web sản xuất thường cần, chẳng hạn như nhiều nhân viên (cụ thể là pre-fork, quản lý vòng đời, xử lý không đồng bộ, v.v.), chuyển hướng, viết lại, v.v.

Khi tôi đề cập đến chuyển hướng / viết lại, tôi đang đề cập đến thực tế là sử dụng Webrick, bạn phải xử lý các đoạn viết lại ở một lớp khác (Rack, Sinatra, Rails, mã Webrick tùy chỉnh, v.v.). Điều này yêu cầu bạn quay thêm các "trình xử lý" ruby để thực hiện viết lại mã của bạn. Đối với một trang web có lưu lượng truy cập thấp, điều này có thể ổn vì bạn có thể có các quy trình được làm nóng sẵn chưa làm gì cả. Tuy nhiên, đối với một trang web có lưu lượng truy cập cao hơn, đây là tải thêm trên máy chủ đối với thứ mà các máy chủ giao diện người dùng (Apache, Nginx, v.v.) có thể xử lý mà không cần quay Ruby * và có thể là các đơn đặt hàng nhanh hơn.

* ví dụ: nếu bạn đang chạy phía sau bộ cân bằng tải, bạn có thể định tuyến tất cả lưu lượng ghi lại đến một máy chủ không được cài đặt ruby và để các máy chủ chính của bạn chỉ quản lý lưu lượng chính. Lưu lượng viết lại này có thể là do thay đổi trang web cho SEO hoặc một cái gì đó tương tự. Một trường hợp khác sẽ là một trang web có nhiều thành phần và có thể một phần là Rails, một phần khác là PHP và cần phải viết lại cho cả hai (tức là viết lại các đường dẫn PHP cũ thành Rails)

— Jim Deville
nguồn

Không thể sử dụng delay_job để xử lý nhiều nhân viên trên Heroku, bất kể bạn sử dụng máy chủ nào?

— Vlad

Đúng vậy, delay_job không liên quan đến Webrick, trừ khi công việc của bạn sử dụng API Webrick (thành thật mà nói thì nó giống như một mùi mã).

— Jim Deville

Tôi đang đề cập đến chuyển hướng bên ngoài ngăn xếp Ruby. Giống như chuyển hướng kiểu mod_rewrite. Về mặt kỹ thuật, bạn có thể chuyển hướng bên trong Rack, hoặc Rails, hoặc, thậm chí có thể Webrick (Tôi có thể sai), nhưng điều đó đòi hỏi phải bắt đầu từ ruby, mà là tương đối chậm so với Apache hoặc Nginx

— Jim Deville

1

@JimDeville - Unicorn cũng được viết bằng Ruby

— Yarin

1

github.com/defunkt/unicorn/tree/master/ext/unicorn_http một phần lớn của Unicorn là trong C

— Jim Deville

4

WEBrick cũng không thể xử lý các URI dài hơn, nếu chúng vượt quá 2083 ký tự, bạn sẽ thấy lỗi. Thin không có những vấn đề này, điều này đã làm cho nó vượt trội hơn - đã được phát triển.

— Michael Schmitz
nguồn

Ngoài ra, Webrick bị mất kết nối và tự động tắt khi theo kinh nghiệm của tôi, tôi đang phát triển phần mềm và khi tôi chọn WeBRICK trong Heroku PaaS, tính năng tự động tắt được bù bằng tốc độ tự động bật cao (được kích hoạt thông qua kiến trúc tự động của Heroku )

— Daniel Antonio Nuñez Carhuayo

3

Tôi không thực sự thích làm phức tạp những thứ đơn giản và tối ưu hóa quá sớm. WEBrick có thể được sử dụng trong sản xuất miễn là nó là một trang web có lưu lượng truy cập thấp. Hầu hết các ứng dụng là.

Nếu trang web của bạn thực hiện một việc gì đó tốn thời gian, ví dụ như gửi e-mail hoặc tạo tệp PDF, bạn nên tạo WEBrick đa luồng . Bạn muốn xử lý nhiều yêu cầu cùng một lúc.

— Nowaker
nguồn

1

Nó đã từng gặp một số vấn đề về bảo mật trong quá khứ, nhưng có vẻ như lý do chính là nó thực sự chậm so với các máy chủ được dự định sản xuất.

— Brett Henning
nguồn

4

Bạn đã thấy một so sánh thống kê? Tôi cũng nghe mọi người nói điều đó (và có lẽ đúng) nhưng thực sự không thể tìm thấy so sánh chỉ số thực ở bất kỳ đâu trên web ...

— Vlad

3

Tôi không nghĩ rằng có ai thực sự đánh giá Webrick vì nó không nhằm mục đích trở thành một máy chủ sản xuất. Unicorn, mỏng hoặc hành khách được hỗ trợ tốt và nhiều lựa chọn tốt hơn

— Jim Deville

0

Điểm yếu lớn nhất của webrick khi chạy ở chế độ sản xuất là nó là máy chủ web quy trình đơn, một luồng, có nghĩa là nó chỉ có khả năng phục vụ một yêu cầu http duy nhất tại một thời điểm.

— Artur Beljajev
nguồn

Nó không phải là luồng đơn. Hoặc nó giống như bất kỳ ngôn ngữ script hiện đại nào được áp dụng (với GIL). Nhưng truy cập cơ sở dữ liệu và IO trong webrick hoàn toàn đa luồng.

— Lothar