Tôi đang cố gắng hiểu đầy đủ các tùy chọn xử lý yêu cầu đồng thời trong Rack. Tôi đã sử dụng async_sinatra để xây dựng một ứng dụng bỏ phiếu dài và hiện đang thử nghiệm với Giá đỡ bằng kim loại trần sử dụng throw :async và/hoặc cờ --threaded của Thin. Tôi cảm thấy thoải mái với chủ đề này, nhưng có một số điều tôi không thể hiểu được. (Không, tôi không hiểu lầm về tính đồng thời cho song song, và có, tôi hiểu những hạn chế áp đặt bởi GIL).Giá đồng thời - rack.multithread, async.callback, hoặc cả hai?
Q1. Các thử nghiệm của tôi cho thấy rằng thin --threaded (tức là rack.multithread=true) chạy yêu cầu đồng thời trong các chuỗi riêng biệt (tôi giả sử sử dụng EM), có nghĩa là yêu cầu chạy dài A sẽ không chặn yêu cầu B (IO sang một bên). Điều này có nghĩa là ứng dụng của tôi không yêu cầu bất kỳ mã hóa đặc biệt nào (ví dụ: gọi lại) để đạt được sự đồng thời (một lần nữa, bỏ qua việc chặn các cuộc gọi DB, IO, v.v.). Đây là những gì tôi tin rằng tôi đã quan sát - nó có đúng không?
Q2. Có một phương tiện khác, được thảo luận nhiều hơn về việc đạt được sự tương tranh, liên quan đến EventMachine.defer và throw :async. Nói đúng ra, các yêu cầu là không phải được xử lý bằng các chuỗi. Chúng được xử lý bằng serially, nhưng vượt qua việc nâng vật nặng và gọi lại cho EventMachine, sử dụng async.callback để gửi phản hồi sau này. Sau khi yêu cầu A đã tải công việc của mình xuống EM.defer, yêu cầu B được bắt đầu. Điều này có đúng không?
Q3. Giả sử ở trên là nhiều hay ít chính xác, có lợi thế cụ thể nào cho một phương thức so với phương thức khác không? Rõ ràng --threaded trông giống như một viên đạn ma thuật. Có bất kỳ nhược điểm nào không? Nếu không, tại sao mọi người lại nói về async_sinatra/throw :async/async.callback? Có lẽ trước đây là "Tôi muốn làm cho ứng dụng Rails của tôi trở nên nhẹ hơn một chút dưới tải nặng" và sau này là ứng dụng phù hợp hơn cho các ứng dụng có nhiều yêu cầu dài hạn? Hoặc có lẽ quy mô là một yếu tố? Chỉ cần đoán ở đây.
Tôi đang chạy Thin 1.2.11 trên MRI Ruby 1.9.2. (FYI, tôi phải sử dụng cờ --no-epoll, vì có a long-standing, supposedly-resolved-but-not-really problem bằng cách sử dụng tính năng epoll và Ruby 1.9.2 của EventMachine. Đó là bên cạnh điểm, nhưng bất kỳ thông tin chi tiết nào đều được chào đón.)
Sự cố epoll phải được khắc phục như được nói trong vé đó, đây là [cam kết] (https://github.com/eventmachine/eventmachine/commit/d684cc3b77a6c401295a3086b5671fe4ec335a64) mà họ đang trỏ đến. – Bitterzoet
Nếu tôi xóa cờ --no-epoll, các yêu cầu luồng của tôi sẽ chuyển từ mili giây sang phút. EM 0.12.10, Ruby 1.9.2-p180. Tôi cho rằng tôi có thể thử biên soạn p290 ... – bioneuralnet
Câu hỏi hay. Tôi đã hỏi một câu hỏi rất giống ở đây: http://stackoverflow.com/questions/8146851/how-to-deploy-a-threadsafe-asynchronous-rails-app và đã thực hiện một số thử nghiệm ở đây: https: // github. com/jjb/threaded-rails-ví dụ (lưu ý rằng trong khi luồng mỏng là thành công không đồng bộ, nó tiêu chuẩn chậm hơn) –