A much better strategy, overall, is to establish some kind of benchmark goal for your program, and then measure how often the program (does | does not) meet that goal.

For example:   “All requests sent to this program will be replied-to within 0.1 seconds.”

The advantage of a metric like this is that it is (a) practical, and (b) taken from the client’s point of view.   A given client does not care how many other clients you have.   But he or she will change their bookmarks forever (heh...) if they receive less-than-stellar service at any time.   (“Bad news has many brothers; Good news stands alone.”)   The data points that you will collect are purely, “pass or fail.” And that is generally good, because if your car missed the turn and smashed into the tree, it really does not matter if you missed the curve by five degrees vs. ten.   You (or, I should say, your next-of-kin) also have zero interest in what was the engine-temperature at the precise moment of (ugh...) impact.

Another big advantage of such a strategy is that you can accurately determine the answer from log files ... i.e. “ex post facto.”   And it can be subjected to all sorts of statistical analyses, again, at your leisure ... after the fact.