Chúng tôi có một ứng dụng có dịch vụ WCF (* .svc) chạy trên IIS7 và các ứng dụng khách khác nhau đang truy vấn dịch vụ. Máy chủ đang chạy Win 2008 Server. Máy khách đang chạy Windows 2008 Server hoặc Windows 2003 server. Tôi nhận được một ngoại lệ sau đây, mà tôi đã thấy trên thực tế có thể liên quan đến một số lượng lớn các vấn đề WCF tiềm ẩn.
System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://www.domain.com/WebServices/myservice.svc/gzip' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. Tôi đã tăng thời gian chờ lên 30 phút và lỗi vẫn xảy ra. Điều này cho tôi biết rằng một cái gì đó khác đang diễn ra, bởi vì số lượng dữ liệu không bao giờ có thể mất 30 phút để tải lên hoặc tải xuống.
Lỗi đến và đi. Hiện tại, nó thường xuyên hơn. Dường như không có vấn đề gì nếu tôi có 3 khách hàng đang chạy đồng thời hoặc 100, nó vẫn xảy ra thỉnh thoảng. Hầu hết thời gian, không có thời gian chờ nhưng tôi vẫn nhận được một vài mỗi giờ. Lỗi đến từ bất kỳ phương thức nào được gọi. Một trong những phương thức này không có tham số và trả về một bit dữ liệu. Một cái khác lấy nhiều dữ liệu làm tham số nhưng thực thi không đồng bộ. Các lỗi luôn bắt nguồn từ máy khách và không bao giờ tham chiếu bất kỳ mã nào trên máy chủ trong dấu vết ngăn xếp. Nó luôn kết thúc bằng:
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
Trên máy chủ: Tôi đã thử (và hiện có) các cài đặt ràng buộc sau:
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"Nó dường như không có tác động.
Tôi đã thử (và hiện có) các cài đặt điều chỉnh sau:
<serviceThrottling maxConcurrentCalls="1500" maxConcurrentInstances="1500" maxConcurrentSessions="1500"/>Nó dường như không có tác động.
Tôi hiện có các cài đặt sau cho dịch vụ WCF.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]Tôi đã chạy với ConcurrencyMode.Multiplemột lúc, và lỗi vẫn xảy ra.
Tôi đã thử khởi động lại IIS, khởi động lại SQL Server cơ bản của mình, khởi động lại máy. Tất cả những điều này dường như không có tác động.
Tôi đã thử tắt tường lửa của Windows. Nó dường như không có tác động.
Trên máy khách, tôi có các cài đặt sau:
maxReceivedMessageSize="2147483647"
<system.net>
<connectionManagement>
<add address="*" maxconnection="16"/>
</connectionManagement>
</system.net>
Khách hàng của tôi đóng các kết nối của nó:
var client = new MyClient();
try
{
return client.GetConfigurationOptions();
}
finally
{
client.Close();
}
Tôi đã thay đổi cài đặt đăng ký để cho phép nhiều kết nối đi hơn:
MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.Tôi vừa mới thử SvcTraceViewer.exe. Tôi đã tìm cách bắt được một ngoại lệ ở phía khách hàng. Tôi thấy rằng thời lượng của nó là 1 phút. Nhìn vào dấu vết phía máy chủ, tôi có thể thấy rằng máy chủ không nhận thức được ngoại lệ này. Thời lượng tối đa tôi có thể thấy là 10 giây.
Tôi đã xem xét các kết nối cơ sở dữ liệu đang hoạt động sử dụng exec sp_whotrên máy chủ. Tôi chỉ có một vài (2-3). Tôi đã xem xét các kết nối TCP từ một máy khách sử dụng TCPview. Nó thường là khoảng 2-3 và tôi đã thấy lên đến 5 hoặc 6.
Nói một cách đơn giản, tôi đang bối rối. Tôi đã thử mọi thứ tôi có thể tìm thấy, và chắc hẳn còn thiếu một thứ rất đơn giản mà một chuyên gia WCF có thể nhìn thấy. Tôi cảm thấy ruột gan rằng có thứ gì đó đang chặn các khách hàng của tôi ở cấp thấp (TCP), trước khi máy chủ thực sự nhận được thông báo và / hoặc có thứ gì đó đang xếp hàng các tin nhắn ở cấp máy chủ và không bao giờ để chúng xử lý.
Nếu bạn có bất kỳ bộ đếm hiệu suất nào mà tôi nên xem, vui lòng cho tôi biết. (vui lòng cho biết giá trị nào là xấu, vì một số bộ đếm này rất khó giải mã). Ngoài ra, làm cách nào tôi có thể ghi kích thước thư WCF? Cuối cùng, có bất kỳ công cụ nào của chúng tôi ở đó cho phép tôi kiểm tra xem tôi có thể thiết lập bao nhiêu kết nối giữa máy khách và máy chủ của mình (độc lập với ứng dụng của tôi)
Cảm ơn vì đã dành thời gian cho tôi!
Thông tin bổ sung được thêm vào ngày 20 tháng 6:
Ứng dụng WCF của tôi hoạt động tương tự như sau.
while (true)
{
Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
Step2GetWorkUnitFromServerViaWCF();
DoWorkLocally(); // takes 5-15minutes.
Step3SendBackResultsToServerViaWCF();
}
Sử dụng WireShark, tôi đã thấy rằng khi lỗi xảy ra, tôi có năm lần truyền lại TCP sau đó là đặt lại TCP sau đó. Tôi đoán là RST đến từ WCF giết chết kết nối. Báo cáo ngoại lệ tôi nhận được là từ Bước 3 hết thời gian.
Tôi đã phát hiện ra điều này bằng cách xem luồng tcp "tcp.stream eq 192". Sau đó, tôi đã mở rộng bộ lọc của mình thành "tcp.stream eq 192 và http và http.request.method eq POST" và thấy 6 POST trong luồng này. Điều này có vẻ kỳ lạ, vì vậy tôi đã kiểm tra với một luồng khác chẳng hạn như tcp.stream eq 100. Tôi có ba POST, điều này có vẻ bình thường hơn một chút vì tôi đang thực hiện ba cuộc gọi. Tuy nhiên, tôi đóng kết nối của mình sau mỗi cuộc gọi WCF, vì vậy tôi đã mong đợi một cuộc gọi trên mỗi luồng (nhưng tôi không biết nhiều về TCP).
Điều tra thêm một chút, tôi đổ tải gói tin http vào đĩa để xem sáu này gọi ở đâu.
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2
Tôi đoán là hai máy khách đồng thời đang sử dụng cùng một kết nối, đó là lý do tại sao tôi thấy các bản sao. Tuy nhiên, tôi vẫn còn một số vấn đề khác mà tôi không thể hiểu được:
a) Tại sao gói tin bị hỏng? Sán mạng ngẫu nhiên - có thể không? Tải được giải nén bằng cách sử dụng mã mẫu này: http://msdn.microsoft.com/en-us/library/ms751458.aspx - Mã có thể bị lỗi đôi khi được sử dụng đồng thời không? Tôi nên kiểm tra mà không có thư viện gzip.
b) Tại sao tôi sẽ thấy bước 1 và bước 2 chạy SAU KHI hoạt động bị hỏng hết thời gian chờ? Đối với tôi, dường như những hoạt động này không nên xảy ra. Có lẽ tôi không nhìn đúng luồng vì hiểu biết của tôi về TCP còn thiếu sót. Tôi có các luồng khác diễn ra cùng lúc. Tôi nên điều tra các luồng khác - xem nhanh các luồng 190-194 cho thấy rằng ĐĂNG BƯỚC 3 có dữ liệu trọng tải thích hợp (không bị hỏng). Thúc đẩy tôi nhìn lại thư viện gzip.