Kết quả SQL lớn qua VPN: các hàng chờ ở đâu

Truy vấn có thể xong trong mili giây mà vẫn mất vài phút để đến một laptop qua VPN. Máy chủ ghi các hàng vào bộ đệm, kết nối vận chuyển chúng và máy khách tiêu thụ chúng, và các giai đoạn này chồng lên nhau thay vì chạy tuần tự. Bất kỳ giai đoạn nào cũng có thể trở thành giới hạn. Hãy tìm giai đoạn thực sự đang chờ trước khi thay đổi băng thông hoặc bật nén.

Ba giai đoạn, một đồng hồ bấm giây

Chia đồng hồ thành hai con số có ý nghĩa khác nhau: thời điểm hàng đầu tiên sẵn sàng và thời điểm hàng cuối cùng được tiêu thụ. Lưới vẽ trang đầu tiên chỉ chứng minh rằng truy vấn đã bắt đầu. Thời gian của kết quả đầy đủ là điều người dùng trải nghiệm khi xuất hoặc cuộn đến cuối.

Ghi lại cả hai con số cùng với văn bản truy vấn, tham số và cài đặt kết nối. Không có ngữ cảnh đó, so sánh là giữa hai công việc khác nhau, không phải hai vị trí.

Đọc sự chờ trước mạng

SQL Server ghi các hàng kết quả vào bộ đệm đầu ra để máy khách lấy, và một máy khách tiêu thụ chậm có thể khiến máy chủ chờ ở lần gửi đó. Loại chờ là ASYNC_NETWORK_IO, và ghi chú khắc phục sự cố của Microsoft liệt kê kết quả lớn và xử lý phía máy khách trong số các nguyên nhân. Sự chờ cho biết đường gửi bị chặn, không phải vì sao.

Một VPN chậm có thể góp phần, nhưng một máy khách định dạng từng hàng, ghi vào tệp hoặc tạm dừng giữa các lô cũng vậy. Tên của sự chờ là một chỉ dấu cho phép đo tiếp theo, không phải phán quyết về đường truyền.

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

Đọc bộ đếm trong khi khối lượng công việc giới hạn chạy, không phải sau một giờ nhàn rỗi, vì bộ đếm tích lũy trộn mọi phiên kể từ khi khởi động phiên bản. So sánh delta trong suốt lần chạy thay vì tổng cả đời. Delta tăng trong khi truyền thu hẹp câu hỏi vào tiêu thụ hoặc phân phối.

Đặt cả hai máy khách trên cùng một đồng hồ

Chạy một khối lượng công việc giới hạn từ máy khách gần cơ sở dữ liệu và từ máy khách từ xa. Giữ truy vấn, tham số, kích thước kết quả và cài đặt kết nối giống hệt nhau. Dùng cùng một phép đo ở cả hai bên, vì thời gian thực thi của máy chủ, thời gian hiển thị lưới và thời gian xuất là ba đồng hồ khác nhau. So sánh một con số phía máy chủ với bộ hẹn giờ xuất phía máy khách tạo ra kết luận không thể kiểm chứng.

Khi đường truyền có vẻ là thủ phạm, hãy để chủ mạng theo dõi mất mát, truyền lại và thông lượng đạt được cho chính luồng đó trong khi truyền. Một bài kiểm tra tốc độ chung có thể dùng tuyến, điểm cuối hoặc kiểu đồng thời khác. Một yêu cầu nhỏ thành công nói rất ít về việc truyền kết quả kéo dài.

Cắt byte trước khi đổ lỗi cho đường truyền

Lọc, tổng hợp và chỉ chọn các cột cần thiết làm giảm cả khối lượng truyền và công việc máy khách làm với từng hàng. Giữ nguyên kết quả dự định, vì báo cáo có thể cần chi tiết mà bản tóm tắt trên màn hình không có.

Đối với các lần xuất lặp lại, một vị trí thực thi được phê duyệt gần cơ sở dữ liệu có thể ghi đầu ra xác định rồi được phân phối một lần. Điều đó thay đổi quy trình làm việc và các kiểm soát truy cập của nó, và không phải là sự cho phép để lại một bản kết xuất không giới hạn trên máy chủ dùng chung.

Nén không phải là biện pháp sửa mặc định. Hỗ trợ và bảo mật phụ thuộc vào giao thức và triển khai thực tế, và một luồng nén mà máy khách giải nén chậm có thể làm trải nghiệm tệ hơn. Hãy đo giai đoạn trước, rồi chọn một thay đổi được hỗ trợ cho giai đoạn đó.