SignalR hub tự host hay không?

Question

Tôi đang làm việc trên một dự án có một trung tâm SignalR khởi động 12 luồng chạy ngắn (Thread mới()). Mỗi chuỗi báo cáo cho khách hàng khi hoàn thành bằng cách sử dụng websockets. Các chủ đề không phải là CPU chuyên sâu, thay vào đó họ nhận được một số thông tin từ các dịch vụ web khác.

Bây giờ tình thế tiến thoái lưỡng nan của tôi là: Tôi có nên tạo một ứng dụng hub signalR tự lưu trữ được chạy như một dịch vụ hay tôi chỉ cần đưa hub vào dự án MVC asp.net của mình?

Hiệu suất tốt nhất là gì?

Answer 1

Nếu hiệu suất là vấn đề tôi sẽ sử dụng Thread Pool chứ không phải Thread mới.

Và tôi sẽ lưu trữ là dịch vụ cửa sổ, vì điều đó sẽ cho phép tôi kiểm soát nhiều hơn về tài nguyên để phân bổ cho chuỗi.

Answer 2

Cách chính xác để thực hiện việc này trong .net 4.5 trở đi là thực hiện việc này đơn luồng không đồng bộ.

ASP.Net should NEVER be creating new threads. Có ý nghĩa hiệu suất rất lớn khi sử dụng một cách rõ ràng các chủ đề với ASP.Net.

Bạn cũng nên biết rằng các chủ đề là sự trừu tượng của tài nguyên CPU giới hạn (bạn đã lưu ý nhiều bằng cách nói rằng các chuỗi của bạn không phải là CPU chuyên sâu). Trong .net 4.5 trở đi, điều đó sẽ cho bạn biết rằng bạn KHÔNG nên sử dụng các luồng. Instead, in this case you should be using a threadless I/O api to call your webservices. Tôi khuyên bạn nên sử dụng mẫu TAP (aka asyncawait), cơ bản là .net 4.5.

Điều này sẽ cho phép bạn mở rộng với một máy tính vừa phải mạnh mẽ đến hàng nghìn yêu cầu đồng thời.

Nếu bạn có tất cả điều này tại chỗ, sử dụng TAP, ASP.Net MVC/IIS sẽ chơi tốt với song song lớn và "luồng". Trong trường hợp này, tôi sẽ khuyên chống lại bằng cách sử dụng dịch vụ cửa sổ, vì bạn sẽ có sự ổn định tốt hơn với IIS làm bootstrapper của bạn (xử lý suốt đời và khởi động lại dịch vụ của bạn nếu nó chết).