Số liệu hiệu suất về các thói quen cụ thể: bất kỳ phương pháp hay nhất nào?

Question

Tôi muốn thu thập số liệu về các quy trình cụ thể của mã của mình để xem nơi tôi có thể tối ưu hóa tốt nhất. Hãy lấy một ví dụ đơn giản và nói rằng tôi có một cơ sở dữ liệu "Lớp" với nhiều "Sinh viên". Giả sử mã hiện tại gọi cơ sở dữ liệu cho mọi sinh viên thay vì lấy tất cả chúng cùng một lúc trong một lô. Tôi muốn xem mỗi chuyến đi đến cơ sở dữ liệu mất bao lâu cho mỗi hàng của sinh viên.

Đây là trong C#, nhưng tôi nghĩ nó áp dụng ở mọi nơi. Thông thường khi tôi tò mò về hiệu suất của một thường trình cụ thể, tôi sẽ tạo một đối tượng DateTime trước khi nó chạy, chạy thường trình, và sau đó tạo một đối tượng DateTime khác sau cuộc gọi và lấy mili giây khác nhau giữa hai để xem nó chạy bao lâu . Thông thường tôi chỉ xuất ra điều này trong dấu vết của trang ... vì vậy nó hơi lo một chút. Bất kỳ thực hành tốt nhất cho điều này? Tôi nghĩ về việc có thể đưa ứng dụng web vào chế độ "chẩn đoán" và ghi nhật ký ghi sự kiện/ghi chi tiết với bất kỳ thứ gì tôi theo sau, nhưng tôi muốn xem liệu ý tưởng heap stackoverflow có ý tưởng hay hơn không.

Answer 1

Một số lần tiếp cận bạn thực hiện sẽ cho bạn cái nhìn tốt nhất về hiệu suất ứng dụng của bạn. Một trong những điều tôi có thể khuyên bạn nên sử dụng System.Diagnostics.Stopwatch thay vì DateTime, DateTime chính xác chỉ tối đa 16 ms trong đó Đồng hồ bấm giờ chính xác đến khi đánh dấu cpu.

Nhưng tôi khuyên bạn nên bổ sung cho nó với các quầy hiệu suất tùy chỉnh để sản xuất và chạy ứng dụng theo profiler trong quá trình phát triển.

Answer 2

Tôi sử dụng phương pháp này và tôi nghĩ nó rất chính xác.

Answer 3

Tôi sử dụng phương pháp này nhân dịp và thấy nó khá chính xác. Vấn đề là trong các ứng dụng lớn với số lượng nhật ký gỡ lỗi khá lớn, nó có thể là một nỗi đau để tìm kiếm thông qua các nhật ký cho thông tin này. Vì vậy, tôi sử dụng các công cụ bên ngoài (tôi lập trình Java chủ yếu, và sử dụng JProbe) cho phép tôi xem trung bình và tổng thời gian cho các phương pháp của tôi, bao nhiêu thời gian được dành riêng cho một phương pháp cụ thể (trái ngược với thời gian tích lũy chi tiêu của phương pháp và bất kỳ phương thức nào nó gọi), cũng như phân bổ bộ nhớ và tài nguyên.

Những công cụ này có thể giúp bạn đo lường hiệu suất của toàn bộ ứng dụng và nếu bạn đang phát triển đáng kể ở một khu vực có hiệu suất quan trọng, bạn có thể nghiên cứu các công cụ có sẵn và tìm hiểu cách sử dụng.

Answer 4

Đối với truy vấn cơ sở dữ liệu, bạn có hai vấn đề nhỏ. Bộ nhớ cache: bộ đệm ẩn dữ liệu và bộ nhớ cache.

Nếu bạn chạy truy vấn một lần, câu lệnh được phân tích cú pháp, chuẩn bị, ràng buộc và thực thi. Dữ liệu được lấy từ các tệp vào bộ nhớ cache.

Khi bạn thực hiện truy vấn lần thứ hai, bộ nhớ cache được sử dụng và hiệu suất thường nhiều, tốt hơn nhiều.

Số hiệu suất "thực" là gì? Đầu tiên hoặc thứ hai? Một số người nói "trường hợp xấu nhất" là số thực và chúng tôi phải tối ưu hóa điều đó. Những người khác nói "trường hợp điển hình" và chạy truy vấn hai lần, bỏ qua câu hỏi đầu tiên. Những người khác nói "trung bình" và chạy trong 30 lần, trung bình tất cả. Nói khác "trung bình điển hình", chạy 31 lần và trung bình 30 cuối cùng.

Tôi đề nghị rằng "30 cuối 31" là số hiệu suất DB có ý nghĩa nhất. Đừng đổ mồ hôi những thứ bạn không thể kiểm soát (phân tích, chuẩn bị, ràng buộc) lần. Mồ hôi những thứ bạn có thể kiểm soát - cấu trúc dữ liệu, tải I/O, chỉ mục, v.v.

Answer 5

Có một số Profilers có sẵn nhưng, thẳng thắn, tôi nghĩ cách tiếp cận của bạn tốt hơn. Cách tiếp cận hồ sơ là quá mức cần thiết. Có lẽ việc sử dụng profilers có giá trị rắc rối nếu bạn hoàn toàn không có manh mối mà nút cổ chai là. Tôi thà dành một ít thời gian để phân tích vấn đề ở phía trước và đưa ra một vài bản in chiến lược hơn là tìm cách thiết lập ứng dụng của bạn để lược tả rồi đổ qua các báo cáo khổng lồ, nơi mọi dòng mã thực thi đều được hẹn giờ.

Answer 6

Nếu bạn đang làm việc với .NET, thì tôi khuyên bạn nên kiểm tra lớp học Stopwatch. Thời gian bạn lấy lại từ đó sẽ chính xác hơn nhiều so với một mẫu tương đương bằng cách sử dụng DateTime.

Tôi cũng khuyên bạn nên xem ANTS Profiler cho các tình huống trong đó hiệu suất đặc biệt quan trọng.

Answer 7

Tôi nghĩ bạn có cách tiếp cận tốt. Tôi khuyên bạn nên tạo các bản ghi "thân thiện với máy" trong (các) tệp nhật ký để bạn có thể phân tích chúng dễ dàng hơn. Một cái gì đó giống như CSV hoặc các bản ghi được phân cách khác được cấu trúc nhất quán.

Answer 8

Điều đáng xem là đầu tư vào một hồ sơ thương mại tốt, đặc biệt nếu bạn mong đợi phải thực hiện điều này lần thứ hai.

Tôi sử dụng, JProfiler, hoạt động trong thế giới Java và có thể đính kèm vào ứng dụng đã chạy, do đó không yêu cầu thiết bị đặc biệt (ít nhất là với các JVM gần đây hơn).

Nó rất nhanh chóng xây dựng danh sách các điểm nóng được sắp xếp trong mã của bạn, hiển thị các phương thức mà mã của bạn dành phần lớn thời gian bên trong. Nó lọc khá thông minh theo mặc định, và cho phép bạn điều chỉnh lọc hơn nữa nếu cần thiết, có nghĩa là bạn có thể bỏ qua chi tiết của các thư viện của bên thứ ba, trong khi chọn ra các phương thức của bạn.

Ngoài ra, bạn nhận được rất nhiều báo cáo hữu ích khác về những gì mã của bạn đang làm. Nó trả cho chi phí của giấy phép trong thời gian tôi đã lưu lần đầu tiên tôi sử dụng nó; Tôi không cần phải thêm vào nhiều câu lệnh khai thác gỗ và xây dựng một cơ chế để trả về kết quả đầu ra: các nhà phát triển của profiler đã làm tất cả điều đó cho tôi.

Tôi không được liên kết với công nghệ ej theo bất kỳ cách nào khác ngoài việc là một khách hàng rất hạnh phúc.