Chúng tôi có một bộ 5 hệ thống đấu giá trực tuyến chạy trên Windows Azure & SQL Azure. Mỗi hệ thống bao gồm một nhân viên web đơn và một hoặc nhiều vai trò web. Mỗi hệ thống đang sử dụng ASP.NET MVC 3 và Entity Framework, Repository Pattern và StructureMap.SQL Azure: Thời gian chờ gián đoạn khác
Vai trò của người lao động chịu trách nhiệm về vệ sinh và điều hành hai nhóm quy trình. Một nhóm được chạy cứ 10 giây một lần, nhóm còn lại mỗi giây. Mỗi quá trình có thể sẽ chạy một truy vấn cơ sở dữ liệu hoặc thủ tục lưu sẵn. Chúng được lên lịch với Quartz.net
Vai trò web phục vụ giao diện công cộng và văn phòng. Trong số các chức năng crud cơ bản khác, cả hai đều cung cấp các màn hình, khi mở, sẽ liên tục gọi các phương thức điều khiển sẽ dẫn đến việc thực hiện các truy vấn chỉ đọc thủ tục lưu sẵn. Tần suất lặp lại là khoảng 2-3 giây cho mỗi khách hàng. Một trường hợp sử dụng điển hình sẽ là 5 cửa sổ văn phòng trở lại mở và 25 cửa sổ người dùng cuối mở - tất cả đều nhấn liên tục vào hệ thống.
Trong một thời gian dài, chúng tôi đã gặp phải lỗi hết thời gian chờ SQL. Ba trong số những cái phổ biến nhất là:
System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
duy nhất kịch bản dự đoán được là trong một cuộc đấu giá, nơi một bộ điều khiển cụ thể -> sproc bắt đầu để timeout trong sự kiện (có lẽ do để tải). Tất cả các lần khác các lỗi xuất hiện là hoàn toàn ngẫu nhiên và đến trong đĩa đơn, hai, và ba vv, ngay cả trong thời gian người dùng không hoạt động. Ví dụ: hệ thống sẽ mất 18 giờ mà không có lỗi và sau đó có thể là 5 - 10 lỗi từ các phương pháp dọn dẹp khác nhau hoặc có thể người dùng đã đăng nhập và xem tài khoản của họ.
thông tin khác:
Tôi đã cố gắng để chạy các truy vấn bị ảnh hưởng/sprocs trên SQL Azure sử dụng cả hai SSMS địa phương và công cụ truy vấn dựa trên web Azure - tất cả dường như để thực hiện một cách nhanh chóng, 1 max thứ hai. Các kế hoạch truy vấn không hiển thị bất kỳ điều gì đáng ngờ mặc dù tôi không phải là chuyên gia về hiệu năng truy vấn SQL, hay bất kỳ loại chuyên gia nào khác cho vấn đề đó J
Chúng tôi đã bao bọc tất cả các khu vực bị ảnh hưởng trong các khối xử lý lỗi tạm thời SQL Azure - nhưng đã thảo luận ở đây http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3, chúng không bị mất thời gian chờ và theo "Valery M", đây là lý do chính đáng.
Chúng tôi không lưu trữ bất kỳ thông tin phiên nào trong cơ sở dữ liệu, mặc dù thông tin thành viên asp.net được lưu trữ trong cơ sở dữ liệu.
Chúng tôi sử dụng 1 "cá thể máy chủ SQL Azure" lưu trữ tất cả 5 cơ sở dữ liệu, hai cho dàn dựng và ba cho sản xuất. Tất cả 5 hệ thống thường hoạt động cùng một lúc mặc dù không chắc rằng nhiều hệ thống sẽ ở trong trạng thái sử dụng tải trực tiếp tại bất kỳ thời điểm nào. Tất cả vai trò web, vai trò công nhân và máy chủ SQL Azure nằm trong cùng Vùng địa lý Azure.
Bất kỳ suy nghĩ nào về nơi chúng ta nên tìm kiếm? Nó sẽ giúp cho mỗi hệ thống máy chủ SQL Azure riêng của nó? ... Không tự giải quyết được - có thể giúp Microsoft mở một vé hỗ trợ và xem qua những gì đang xảy ra với ứng dụng của chúng tôi không - làm thế nào để thực hiện điều này?
Xin cảm ơn trước.
Ilan
Ilan, Tôi đang gặp cùng một loại lỗi trong các ứng dụng ra ngay bây giờ. Bạn đã làm gì? Nhân tiện, trong bài báo lỗi tạm thời đó, Valery M nói rằng nếu kế hoạch thực hiện và các chỉ mục cơ sở dữ liệu trông ổn, thì có thể OK sử dụng mẫu cho ít nhất một số thời gian chờ mà bạn không thể giải quyết. –