Một cuộc gọi lớn so với nhiều cuộc gọi TSQL nhỏ hơn

Question

Tôi có câu hỏi về hiệu suất ADO.NET/TSQL. Chúng tôi có hai lựa chọn trong ứng dụng của chúng tôi:

1) Một cuộc gọi cơ sở dữ liệu lớn với nhiều bộ kết quả, sau đó trong bước mã qua từng bộ kết quả và điền các đối tượng của tôi. Điều này dẫn đến một chuyến đi vòng đến cơ sở dữ liệu.

2) Nhiều cuộc gọi cơ sở dữ liệu nhỏ.

Có nhiều cách sử dụng lại mã nhiều hơn với Tùy chọn 2 là một lợi thế của tùy chọn đó. Nhưng tôi muốn nhận được một số đầu vào về chi phí hiệu suất là gì. Có hai chuyến đi khứ hồi nhỏ hai lần chậm như một chuyến đi khứ hồi lớn đến cơ sở dữ liệu, hay chỉ là một nhỏ, nói rằng mất hiệu suất 10%? Chúng tôi đang sử dụng C# 3.5 và Sql Server 2008 với các thủ tục được lưu trữ và ADO.NET.

Answer 1

Tôi nghĩ rằng một phần sẽ phụ thuộc vào thời điểm bạn cần dữ liệu. Ví dụ: nếu bạn trả lại mười tập dữ liệu trong một quy trình lớn và xem tất cả mười tập dữ liệu trên màn hình cùng một lúc, hãy truy cập nó. Nhưng nếu bạn trả lại mười tập dữ liệu và người dùng chỉ có thể nhấp qua các trang để xem ba trong số đó thì việc gửi những người khác là một sự lãng phí tài nguyên mạng và máy chủ. Nếu bạn trả lại mười tập dữ liệu nhưng người dùng thực sự chỉ cần xem các bộ bảy và tám sau khi thực hiện thay đổi đối với các tập 5 và 6, thì người dùng sẽ thấy thông tin sai nếu bạn trả lại quá sớm.

Nếu bạn sử dụng các procs được lưu trữ riêng biệt cho từng tập dữ liệu được gọi trong một thư mục gốc được lưu trữ, không có lý do gì tại sao bạn không thể sử dụng lại mã ở nơi khác, vì vậy việc sử dụng lại mã không thực sự là vấn đề trong đầu.

Answer 2

Nếu bạn quan tâm đến hiệu suất, hãy thử kiểm tra cả hai và xem thử nghiệm nào hoạt động tốt hơn.

Cá nhân tôi thích phương pháp thứ hai. Nó làm cho cuộc sống dễ dàng hơn cho các nhà phát triển, làm cho mã trở nên dễ sử dụng hơn và mô đun hóa mọi thứ để những thay đổi trên con đường trở nên dễ dàng hơn.

Answer 3

Cá nhân tôi sẽ đi với 1 chuyến đi khứ hồi lớn hơn.

Điều này chắc chắn sẽ bị ảnh hưởng bởi khả năng sử dụng lại chính xác mã gọi điện và cách nó có thể được tái cấu trúc.

Nhưng như đã đề cập, điều này sẽ tùy thuộc vào tình huống chính xác của bạn, nơi khả năng duy trì so với hiệu suất có thể là một yếu tố.

Answer 4

Cá nhân tôi thích lựa chọn hai vì lý do bạn đã nêu: tái sử dụng mã

Nhưng xem xét việc này: đối với các yêu cầu nhỏ độ trễ có thể dài hơn những gì bạn làm với yêu cầu. Bạn phải tìm sự cân bằng phù hợp.

Answer 5

Không tối ưu hóa để có hiệu suất cho đến khi cần thiết phải làm như vậy. Điều này có nghĩa là bạn nên phân tích các mẫu sử dụng dự đoán của mình và xác định tần suất sử dụng điển hình cho quá trình này sẽ là gì và độ trễ của giao diện người dùng sẽ là kết quả của thiết kế hiện tại. Nếu người dùng sẽ nhận được phản hồi từ ứng dụng ít hơn một vài (2-3) giây và tải ứng dụng từ quá trình này không phải là tải không đủ về dung lượng máy chủ, thì đừng lo lắng về nó. Nếu otoh người dùng đang chờ đợi một khoảng thời gian không thể chấp nhận cho một phản hồi (chủ thể nhưng chắc chắn có thể đo lường) hoặc nếu máy chủ đang bị quá tải, thì đã đến lúc bắt đầu tối ưu hóa. Và sau đó, các kỹ thuật tối ưu hóa nào sẽ có ý nghĩa nhất, hoặc là hiệu quả nhất về chi phí, phụ thuộc vào những gì phân tích của bạn về vấn đề cho bạn biết.

Vì vậy, trong khi chờ đợi, hãy tập trung vào khả năng bảo trì. Điều đó có nghĩa là, trong trường hợp của bạn, hãy sử dụng lại mã

Answer 6

Là nhà phát triển ADO.Net, công việc của bạn là làm cho mã đúng, rõ ràng và có thể duy trì được càng tốt. Điều này có nghĩa là bạn phải tách riêng mối quan tâm của mình.

Đó là công việc của công nghệ kết nối SQL Server để làm cho nó nhanh.

Nếu bạn triển khai ứng dụng đúng, rõ ràng, có thể bảo trì để giải quyết các vấn đề kinh doanh và hóa ra truy cập cơ sở dữ liệu là nút cổ chai lớn ngăn hệ thống hoạt động trong giới hạn chấp nhận được, bắt đầu tiếp tục các cách khắc phục sự cố. Điều này có thể hoặc không bao gồm các truy vấn cơ sở dữ liệu hợp nhất.

Answer 7

Nghe có vẻ hơi rõ ràng, nhưng chỉ gửi những gì bạn cần trong một cuộc gọi.

Ví dụ: chúng tôi có một proc "getStuff" được lưu trữ để trình bày. "UpdateStuff" proc gọi proc "getStuff" và phương thức trình bao bọc máy khách cho "updateStuff" dự kiến ​​gõ "Thing". Vì vậy, một chuyến đi vòng.

Máy chủ trò chuyện là một thứ bạn ngăn chặn trước với nỗ lực tối thiểu. Sau đó, bạn có thể điều chỉnh DB hoặc mã máy khách khi cần ... nhưng thật khó để tính toán các vòng lặp sau này cho dù mã của bạn chạy nhanh đến mức nào. Trong cực đoan, điều gì xảy ra nếu máy chủ web của bạn ở một quốc gia khác với máy chủ DB của bạn ...?

Chỉnh sửa: đó là thú vị để lưu ý những kẻ SQL (HLGEM, astander, tôi) nói rằng "một chuyến đi" và những kẻ khách hàng nói "nhiều, mã tái sử dụng" ...

Answer 8

Tôi đang phải vật lộn với vấn đề này bản thân mình . Và tôi chưa có câu trả lời, nhưng tôi có một số suy nghĩ.

Sau khi xem xét các câu trả lời do người khác đưa ra cho đến thời điểm này, vẫn còn tùy chọn thứ ba.

Trong lần đăng ký của tôi, khoảng mười hoặc mười hai cuộc gọi được thực hiện tới máy chủ để nhận dữ liệu tôi cần. Một số datafields là trường tối đa varchar và varbinary (hình ảnh, tài liệu lớn, video và các tập tin âm thanh). Tất cả các cuộc gọi của tôi đều đồng bộ - tức là, trong khi dữ liệu được yêu cầu, người dùng (và chương trình phía máy khách) không còn cách nào khác ngoài chờ đợi. Anh ta chỉ có thể muốn đọc hoặc xem dữ liệu mà chỉ có ý nghĩa tổng thể khi nó là TẤT CẢ ở đó, không chỉ một phần ở đó. Quá trình này, tôi tin rằng, chậm hơn theo cách này và tôi đang trong quá trình phát triển một phương pháp thay thế dựa trên các cuộc gọi không đồng bộ tới máy chủ từ một DLL libaray, điều này làm tăng sự kiện cho khách hàng để thông báo tiến trình cho khách hàng. Máy khách được lập trình để xử lý các sự kiện DLL và thiết lập một biến ở phía máy khách cho biết các cuộc gọi chich đã được hoàn thành. Chương trình khách hàng sau đó có thể làm những gì nó phải làm để chuẩn bị dữ liệu nhận được trong cuộc gọi # 1 trong khi DLL đang tiến hành không đồng bộ để lấy dữ liệu của cuộc gọi # 2. Khi khách hàng đã sẵn sàng xử lý dữ liệu của cuộc gọi số 2, nó phải kiểm tra trạng thái và chờ để tiếp tục nếu cần thiết (Tôi hy vọng điều này sẽ là ngắn hoặc không chờ chút nào). Theo cách này, cả phần mềm máy chủ và phía máy khách đều đang hoàn thành công việc một cách hiệu quả hơn.