Thiết kế kiểm tra so sánh hiệu suất thư viện

Question

Tôi đang sẵn sàng để thực hiện một loạt các so sánh hiệu suất của nhiều sản phẩm khác nhau.

Tôi cần làm gì để thể hiện độ tin cậy trong các bài kiểm tra? Làm thế nào để thiết kế các bài kiểm tra điểm chuẩn của tôi để chúng được tôn trọng?

Tôi cũng quan tâm đến bất kỳ đề xuất nào về thiết kế thực tế của các thử nghiệm. Cách tải dữ liệu mà không ảnh hưởng đến các bài kiểm tra (Nguyên tắc bất định Heisenberg), hoặc các cách để theo dõi ... vv

Answer 1

Đây là một chút khó khăn để trả lời mà không biết loại sản phẩm "ngoài kệ" nào bạn đang cố gắng đánh giá. Bạn đang tìm kiếm phản hồi UI, thông lượng (ví dụ: email, giao dịch/giây), thời gian khởi động, v.v. - tất cả đều có tiêu chí khác nhau về các biện pháp bạn nên theo dõi và các công cụ khác nhau để thử nghiệm hoặc đánh giá. Nhưng để trả lời một số câu hỏi chung của bạn:

1. Độ tin cậy - điều này là quan trọng. Hãy thử để đảm bảo rằng bất cứ điều gì bạn đang đo có ít chạy để chạy phương sai. Sử dụng kỹ thuật thực hiện một số lần chạy cùng một kịch bản, loại bỏ các ngoại lệ (tức là thấp nhất và cao nhất) và đánh giá giá trị trung bình/tối đa/phút/trung bình của bạn. Nếu bạn đang làm một số loại kiểm tra thông lượng, hãy xem xét làm cho nó chạy dài để bạn có một bộ mẫu tốt. Ví dụ, nếu bạn đang xem một cái gì đó như Microsoft Exchange và do đó đang sử dụng quầy perf của họ, hãy thử để đảm bảo rằng bạn đang dùng mẫu thường xuyên (một lần mỗi giây hoặc vài giây) và có chạy thử nghiệm cho 20 phút hoặc lâu hơn. Một lần nữa, chop ra vài phút đầu tiên và vài phút cuối cùng để loại bỏ bất kỳ tiếng ồn khởi động/tắt máy nào.

2. Heisenburg - khó khăn. Trong hầu hết các hệ thống hiện đại, tùy thuộc vào ứng dụng/biện pháp bạn đang đo lường, bạn có thể giảm thiểu tác động này bằng cách thông minh về những gì/cách bạn đang đo lường. Đôi khi (như trong ví dụ Exchange), bạn sẽ thấy gần 0 tác động. Cố gắng sử dụng ít nhất các công cụ xâm lấn nhất có thể. Ví dụ: nếu bạn đang đo thời gian khởi động, hãy xem xét sử dụng xperfinfo và sử dụng các sự kiện được tích hợp vào hạt nhân. Nếu bạn đang sử dụng perfmon, đừng làm ngập hệ thống với các quầy không liên quan mà bạn không quan tâm. Nếu bạn đang thực hiện một số thử nghiệm chạy dài hạn, hãy lấy lại khoảng thời gian lấy mẫu của bạn.

Cũng cố gắng loại bỏ bất kỳ nguồn biến đổi môi trường hoặc nguồn gây nhiễu nào. Nếu bạn đang làm một cái gì đó mạng chuyên sâu, hãy xem xét cô lập mạng. Hãy thử tắt mọi dịch vụ hoặc ứng dụng mà bạn không quan tâm. Hạn chế bất kỳ loại đĩa IO, hoạt động bộ nhớ chuyên sâu, vv Nếu đĩa IO có thể giới thiệu tiếng ồn trong một cái gì đó là CPU bị ràng buộc, xem xét việc sử dụng SSD.

Khi thiết kế thử nghiệm của bạn, hãy lưu ý đến tính lặp lại. Nếu bạn thực hiện một số loại kiểm tra loại microbenchmark (ví dụ: kiểm tra đơn vị perf) thì có hỗ trợ cơ sở hạ tầng của bạn chạy cùng một hoạt động n lần giống hệt nhau. Nếu bạn đang lái xe giao diện người dùng, cố gắng không thể chất di chuột và thay vào đó sử dụng lớp trợ năng cơ bản (MSAA, UIAutomation, v.v.) để nhấn điều khiển trực tiếp theo lập trình.

Một lần nữa, đây chỉ là lời khuyên chung. Nếu bạn có thêm chi tiết cụ thể thì tôi có thể cố gắng theo dõi với nhiều hướng dẫn thích hợp hơn.

Tận hưởng!

Answer 2

Tại sao bạn quan tâm đến hiệu suất? Trong cả hai trường hợp, thời gian thực hiện để viết thư đến bất cứ nơi nào bạn lưu trữ nhật ký của mình sẽ chậm hơn rất nhiều so với bất kỳ điều gì khác.

Nếu bạn thực sự thực hiện việc ghi nhật ký đó, bạn có thể cần lập chỉ mục các tệp nhật ký để có thể tìm thấy mục nhập nhật ký bạn cần, tại thời điểm đó bạn không thực hiện ghi nhật ký chuẩn.

Answer 3

Câu hỏi của bạn rất thú vị, nhưng hơi mơ hồ, bởi vì không biết phải kiểm tra điều gì thì không dễ dàng cho bạn một số manh mối.

Bạn có thể kiểm tra hiệu suất từ ​​nhiều góc độ khác nhau, sau đó, tùy thuộc vào mục đích sử dụng hoặc mục tiêu của thư viện, bạn nên thử phương pháp này hoặc cách tiếp cận khác; Tôi sẽ cố gắng liệt kê một số trong những điều bạn có thể phải xem xét để đo:

• Multithreading: nếu thư viện sử dụng nó hoặc phần mềm của bạn sẽ sử dụng thư viện trong một bối cảnh đa luồng sau đó bạn có thể phải kiểm tra với nhiều bộ vi xử lý khác nhau và cấu hình đa xử lý để xem cách phản ứng.
• Thời gian khởi động: tầm quan trọng phụ thuộc vào mức độ mạnh mẽ bạn sẽ sử dụng thư viện và bản chất của sản phẩm đang được xây dựng với nó (máy khách, máy chủ ...).
• Thời gian phản hồi: đối với việc này không thực hiện lần thực hiện đầu tiên, hãy thử thực hiện cùng một cuộc gọi nhiều lần sau số đầu tiên và thực hiện trung bình. Sử dụng System.Diagnostics.StopWatch có thể là rất hữu ích cho điều đó.
• Bộ nhớ mức tiêu thụ: phân tích mức tăng trưởng, hãy cẩn thận với các số mũ;). Đi thêm và đo số lượng các đối tượng đang được tạo và xử lý.
• Phản hồi: bạn không nên chỉ đo hiệu suất thô, cách người dùng cảm thấy tốc độ của sản phẩm là cũng rất quan trọng.
• Mạng: nếu thư viện sử dụng tài nguyên trên mạng bạn có thể phải thử nghiệm nó với băng thông khác nhau và độ trễ cấu hình, có phần mềm để mô phỏng các tình huống này.
• dữ liệu: cố gắng tạo ra nhiều thử nghiệm gói dữ liệu khác nhau, cố gắng để bù đắp, cho dụ: một bó lớn của dữ liệu thô, sau đó một tập hợp lớn làm bằng nhiều những phần nhỏ hơn, một sự lặp lại lâu dài với nhỏ mảnh dữ liệu, ...

cụ:

• System.Diagnostics.Stopwatch: cần thiết cho phương pháp benchmarking gọi
• Performance counters: bất cứ khi nào có sẵn, chúng rất hữu ích để biết điều gì đang xảy ra bên trong, cho phép bạn theo dõi phần mềm mà không ảnh hưởng đến hiệu suất của phần mềm.
• Profilers: có một số bộ nhớ tốt và hiệu suất profilers trên thị trường, nhưng như bạn đã nói, chúng luôn ảnh hưởng đến các phép đo. Chúng rất tốt cho việc tìm ra tắc nghẽn trong phần mềm của bạn, nhưng tôi không nghĩ bạn có thể sử dụng chúng để kiểm tra so sánh.