Vì sao ứng dụng SQL lắm lời bò chậm qua VPN và nên gộp những gì

Một biểu mẫu mở dưới một giây trong mạng cục bộ lại mất năm giây qua VPN, trong khi bản sao tệp trên cùng đường truyền vẫn chạy hết tốc độ. Khác biệt không phải băng thông. Biểu mẫu chờ một chuỗi câu trả lời và trả giá trọn vòng khứ hồi ở mỗi bước, còn bản sao tệp giữ các byte bay liên tục. Hãy đếm những lần chờ đó trước khi động vào đường truy cập.

Triệu chứng là một màn hình, không phải một truy vấn

Mọi truy vấn trên màn hình đó đều có thể nhanh mà màn hình vẫn chậm, vì tổng là tổng các lần chờ chứ không phải tổng thời gian thực thi. Một câu lệnh chạy trong hai mili giây vẫn tốn trọn một vòng khứ hồi khi máy khách phải nhận kết quả trước khi gửi câu tiếp theo. Trên một đường có độ trễ bốn mươi mili giây, một trăm lời gọi phụ thuộc cộng lại khoảng bốn giây trước khi bất kỳ việc kết xuất nào bắt đầu. Phép tính này là mô hình của sự chờ đợi, không phải phép đo đường truyền của bạn.

Đó là lý do bài kiểm tra tốc độ trông vô can. Truyền khối đo thông lượng, biểu mẫu lắm lời đo độ trễ, và một VPN có thể xuất sắc ở mặt này mà vẫn bình thường ở mặt kia. Vì vậy chẩn đoán màn hình là đo màn hình chứ không phải đo đường truyền.

Ghi lại thời gian từ đầu đến cuối của một thao tác người dùng trước khi thay đổi bất cứ điều gì. Con số đó là đường cơ sở duy nhất cho biết một bản sửa về sau có hiệu quả hay không.

Đếm các lần chờ tuần tự trong một thao tác người dùng

Hãy đo ở máy khách thay vì đoán. Trong psql, \timing on in ra thời gian đã trôi của từng câu lệnh, và EXPLAIN (ANALYZE, BUFFERS) cho thấy máy chủ thực sự dùng bao nhiêu phần thời gian đó cho công việc.

Khoảng chênh giữa hai con số đó là chi phí mạng và máy khách của bạn. Nếu một câu lệnh thực thi trong hai mili giây mà máy khách ghi nhận sáu mươi, thì năm mươi tám còn lại là đường đi và xử lý cục bộ, và không chỉ mục nào loại bỏ được chúng. Lặp lại phép so sánh đó cho mọi câu lệnh mà màn hình phát ra và cộng các khoảng chênh chứ không cộng thời gian thực thi.

Ghi kết quả thành số lần chờ tuần tự. Đó chính là đại lượng mà hai phần tiếp theo có thể giảm, và đó là con số bạn có thể tranh luận bằng bằng chứng.

Gộp các lời gọi độc lập, giữ lại những lời gọi phụ thuộc

Hai câu lệnh không đọc kết quả của nhau có thể đi cùng nhau và được thu gom một lần, biến hai lần chờ thành một. Hai câu lệnh mà câu thứ hai cần giá trị từ câu thứ nhất thì không thể, vì sự phụ thuộc là thật và gộp lại sẽ thay đổi việc chương trình làm. Hãy phân các lời gọi vào hai đống đó trước khi viết lại bất cứ điều gì, và kích thước mỗi đống cho biết điều gì khả thi.

Công việc theo tập hợp loại bỏ các lần chờ triệt để hơn gộp lô. Một truy vấn trả về các hàng mà vòng lặp từng lấy từng hàng một sẽ loại bỏ cả vòng lặp lẫn các vòng khứ hồi. Hãy tìm vòng lặp trước, vì đó thường là lợi ích lớn hơn và là thay đổi dễ xem xét hơn.

Một lô vẫn phải giữ được việc xử lý lỗi và ranh giới giao dịch. Nối những câu lệnh không liên quan thành một chuỗi không phải là tối ưu an toàn, và một lô che giấu câu lệnh thất bại sau một lần gửi thành công thì tệ hơn những lần chờ mà nó tiết kiệm.

Dùng lại kết nối trước khi mua băng thông

Một kết nối mới tốn phân giải tên, bắt tay TCP, thương lượng TLS và xác thực, và trên đường có độ trễ cao thì mỗi thứ đó là thêm một vòng khứ hồi trước khi truy vấn đầu tiên chạy. Các bể kết nối tồn tại để trả chi phí đó một lần cho mỗi tiến trình thay vì một lần cho mỗi lời gọi.

Trong ADO.NET, đóng hoặc dispose một kết nối trong bể sẽ trả nó về để dùng lại thay vì mở một kết nối vật lý mới, nên mẫu trông như rò rỉ thường lại là cách dùng đúng. Hãy xác minh bể thực sự được dùng thay vì giả định: ghi log việc tạo kết nối vật lý, hoặc theo dõi số phiên trên máy chủ trong khi màn hình chạy. Hướng dẫn hiệu năng SQL nói cùng một điểm về việc giảm vòng khứ hồi và gộp các lời gọi ad hoc thường xuyên, kèm ví dụ riêng cho dịch vụ mà bạn nên ánh xạ vào triển khai của mình.

Việc tạo bể loại bỏ chi phí thiết lập và để nguyên các lần chờ truy vấn tuần tự. Đó là điều kiện tiên quyết cho một phép đo sạch, không phải một bản sửa tự thân.

Cân nhắc đưa việc thực thi đến gần dữ liệu hơn

Chạy ứng dụng gần cơ sở dữ liệu thay thế nhiều lần trao đổi từ xa với cơ sở dữ liệu bằng một phiên hiển thị từ xa duy nhất. Với khối lượng công việc lắm lời, đó có thể là thay đổi lớn, và nó là thay đổi vận hành nhiều như thay đổi hiệu năng: quản lý phiên, kiểm soát truy cập, triển khai phần mềm và trải nghiệm người dùng đều di chuyển cùng ứng dụng.

Hãy đo giao diện thực tế và dữ liệu mà nó truyền trước khi giả định hướng nào nhanh hơn. Một phiên máy tính từ xa truyền điểm ảnh, và một màn hình đồ họa dày đặc có thể chạy kém hơn trên cùng đường đó so với các truy vấn mà nó thay thế, nhất là khi máy khách vẽ lại liên tục.

Sau đó lặp lại thao tác ban đầu và so sánh ba con số: số lần chờ tuần tự, khối lượng kết quả và thời gian hoàn thành từ đầu đến cuối. Một cải tiến làm thay đổi tác vụ người dùng được đo trong khi vẫn giữ đúng dữ liệu và chính sách truy cập là cái đáng giữ lại.