[SERVER-13576] Add lightweight instrumentation 'probes' for unit tests Created: 14/Apr/14  Updated: 06/Dec/22  Resolved: 21/Jan/16

Status: Closed
Project: Core Server
Component/s: Performance
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Ben Becker Assignee: Backlog - Performance Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-2541 Expose performance counters (Windows) Backlog
is related to SERVER-5702 Unit test framework improvements (uni... Closed
Assigned Teams:
Product Performance
Backwards Compatibility: Fully Compatible
Participants:

 Description   

When profiling the performance of a given code path, certain metrics can provide valuable insight as to how the profiled code will impact system performance. An obvious example is wallclock time, but additional metrics like L2/L3/TLB cache misses, remote NUMA node memory accesses, page faults, instructions per cycle, and cycle counts can paint a more detailed picture.

The idea here is to add a simple mechanism which collects such metrics to the unit test framework.



 Comments   
Comment by Chung-yen Chang [ 21/Jan/16 ]

We will be adding profile (linux perf or Intel vtune, etc.) collection to the internal performance testing infrastructure that we have been building. We will be able to cover the analysis need that way.

Comment by Ben Becker [ 16/Apr/14 ]

schwerin, a microbenchmarking framework would be just fine, as long as the microbenchmarks can be built/linked against server code (similar to unit and db tests).

The only benefit of instrumentable unit tests over a new microbenchmark framework is code reuse; benchmarks need to assert correctness, so adding a the concept of a 'probe' seems simple and unobtrusive. That said, I'm perfectly amenable to either approach.

Comment by Andy Schwerin [ 16/Apr/14 ]

benjamin.becker, it seems to me that we might do better building a microbenchmark framework, and then use existing tools such as Linux perf or Intel vtune to instrument and monitor those benchmarks. What's the added benefit of this approach? I see a certain amount of added maintenance cost in identifying the counters and maintaining the code to set and read them on supported platforms.

Comment by Ben Becker [ 14/Apr/14 ]

A very simple approach to this is outlined here. Additional stats require system infrastructure like an Intel PCM interface or the Linux performance counters framework.

Generated at Thu Feb 08 03:32:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.