When even one sample from a set of samples contained an error, the responding time graph displays zero milliseconds for the entire build. This is undesirable, as:

• even error-generation takes time (and should be plotted);
• it masks the response times for the requests that did not result in an error (which is annoying if there are many, many samples of which just a low percentage resulted in errors.

On the dashboard, the "Responding Time" and "Percentage of Errors" graphs are situated next to each-other. This allows the user to evaluate easily if there were errors for the provided response times. This further removes the need to 'hide' samples that contain errors (as it's pretty clear that there were errors, if any).

To illustrate, see the graph below. About half way through the build history, we implemented an improvement that:

1. fixed the low percentage of errors that we had;
2. improved response time considerably.

The first glance on the graphs however make it look like things got worse (as there are suddenly a number of lines that are not 'zero' any more.

The graph below is based on the same data, but does not 'hide' errors.

As you can see, the graph allows users to analyze the actual results a lot better.

I propose to stop 'hiding' the errors, as that results in non-truthful graphs.

The fix for this issue is almost trivial. In class PerformanceProjectAction, the following if-statement needs to be replaced:

if (uriReport.isFailed()) {
  // we set duration as 0 for failed tests
  dataSetBuilderAverage.add(0, uriReport.getUri(), label);
} else {
  dataSetBuilderAverage.add(uriReport.getAverage(), uriReport.getUri(), label);
}