Gọi lại WCF, proxy và thread-safety

Question

Với dịch vụ duplex WCF (NetTcpBinding) được cấu hình để tạo một cá thể dịch vụ mới cho mỗi máy khách mới (xem pattern publish-subscribe), bạn có thể nhận được một trường hợp gọi lại cụ thể cho từng cá thể dịch vụ. Vì các cá thể khác nhau được tạo ra, các phương thức thuộc các callback khác nhau có thể được gọi ra từ các luồng khác nhau đồng thời.

• Điều gì sẽ xảy ra nếu nhiều chủ đề cố gắng gọi cùng một phương thức trên cùng một cuộc gọi lại?
• Điều gì sẽ xảy ra nếu họ cố gắng gọi các phương thức khác nhau nhưng đối với cùng một cuộc gọi lại?
• Chúng tôi có nên quản lý quyền truy cập đồng thời vào các phương thức này từ nhiều luồng không? Trong cả hai trường hợp?

Hãy xem xét phía khách hàng giao tiếp với dịch vụ: để đảm bảo rằng khách hàng có thể sử dụng dịch vụ, bạn phải khởi tạo proxy mới và để gọi các phương thức được xác định trong dịch vụ, bạn phải gọi các phương thức tương ứng của proxy.

• Điều gì sẽ xảy ra nếu nhiều chủ đề cố gắng gọi cùng một phương thức trên cùng một cá thể proxy?
• Điều gì sẽ xảy ra nếu họ cố gắng gọi các phương thức khác nhau nhưng đối với cùng một phiên bản proxy?
• Chúng tôi có nên quản lý quyền truy cập đồng thời vào các phương thức này từ nhiều luồng không? Trong cả hai trường hợp?

Answer 1

Câu trả lời cho hầu hết các câu hỏi đó phụ thuộc vào cách bạn quản lý đồng thời dịch vụ của mình. Không có câu trả lời dứt khoát vì nó phụ thuộc vào những gì bạn đặt cho ConcurrencyMode và InstanceContextMode của mình. Quản lý đồng thời của WCF sẽ cho phép bạn tinh chỉnh hành vi và hiệu suất luồng của dịch vụ. Đọc dài và gian khổ (nhưng rất chi tiết) trên concurrency management is available on MSDN.

InstanceContextMode cho phép bạn xác định cách dịch vụ của bạn sẽ được khởi tạo. Đối với một dịch vụ thực hiện rất nhiều nhiệm vụ nặng nề và xử lý nhiều cuộc gọi, ý tưởng chung là sử dụng tính năng instence PerCall như với các yêu cầu của máy khách gửi đến này sẽ được xử lý trên một cá thể riêng biệt của dịch vụ mỗi lần.

ConcurrencyMode, trình phát chính, sẽ cho phép bạn xác định số lượng chủ đề có thể truy cập phiên bản dịch vụ tại một thời điểm nhất định. Trong ConcurrencyMode=Single, chỉ một chủ đề có thể truy cập phiên bản dịch vụ tại một thời điểm. Điều này cũng tùy thuộc vào việc bạn đã bật SynchronizationConext, nếu SynchronizationConext=true thì các cuộc gọi của khách hàng sẽ được xếp hàng đợi nếu dịch vụ của bạn đang trong quá trình trả lời một yêu cầu khác. Vì vậy, các cuộc gọi dịch vụ đến sẽ được xếp hàng đợi cho đến khi các cuộc gọi trước được xử lý trước tiên. Với cài đặt ConcurrencyMode=Multiple, bất kỳ số lượng chủ đề nào đều được phép truy cập vào một cá thể dịch vụ, nghĩa là dịch vụ của bạn có thể trả lời càng nhiều cuộc gọi càng tốt vì có bao nhiêu luồng (liên quan trực tiếp đến nguồn CPU) có sẵn trong nhóm Chủ đề. Việc bắt giữ với nhiều chế độ tương tranh là dịch vụ của bạn không đáng tin cậy theo thứ tự nhận được và phản hồi cuộc gọi, vì trạng thái sẽ không được quản lý vì SynchronizationContext sẽ được đặt thành false theo mặc định. Bản tóm tắt ngắn và đẹp trên concurrency modes and thread safety is available on MSDN.

Các cài đặt này sẽ ảnh hưởng đến hiệu suất dịch vụ khi sử dụng kết hợp với chế độ InstanceContext, xem this pretty nice article which explores various concurrency modes and instance context settings and their effects on performance (mặc dù có vẻ như kết quả chỉ trong môi trường tự lưu trữ, có thể không quá đại diện cho thời gian bạn sẽ nhận được khi lưu trữ IIS).

Cách bạn quản lý đồng thời của dịch vụ sẽ ảnh hưởng rất lớn đến hiệu suất của dịch vụ. Lý tưởng nhất là bạn muốn cung cấp càng nhiều luồng càng tốt (hãy thử tăng các chuỗi tối thiểu của ThreadPool) cho dịch vụ của bạn và tránh các cuộc gọi dịch vụ đến được xếp hàng đợi miễn là dịch vụ của bạn có tài nguyên tính toán lúc xử lý. Nhưng việc sử dụng đa luồng quá mức sẽ làm mất đi sự quản lý nhà nước và thứ tự mà bạn trả lời các yêu cầu của khách hàng.