Benchmarks

The GOX testing system can run the same functions completed in Test in Benchmark mode.

This mode repeats the pipeline in memory and generates global metrics and by step on the routes or Actions utilizadas.

Run a Benchmark

gox test -bench IndexTest

-bench it accepts a regular expression applied to the name of the functions. Test; there is no different suffix reserved for benchmarking.

See Execution to select files and use common command options.

Configuration

The Benchmark fields belong to test.Config:

config := test.Config{
	Iterations: 1000,
	Warmup: 100,
	BenchSampleRate: 0.1,
}

The page of Configuration explains how these properties share test.Config with the session and temporary modifications of the server.

IsBench

test.IsBench() allows you to know the way used by the runner.

if test.IsBench() {
	test.Pass("Ejecutando mediciones")
}

It is not normally necessary to change the logic: gox test -bench runs the same test.Execute() used by the functional test.

Benchmark

test.Benchmark() is reserved for direct future use. At present, the benchmarks must be run with gox test -bench and test.Execute().

Not to be used test.Benchmark() as a substitute for test.Execute() in the current tests.

Metrics

The result may include:

The pipelines also show independent metrics for each step.

Allocation sampling

BenchSampleRate controls the proportion of iterations used to measure allocations. The result indicates the amount of samples and can identify files, lines and handlers .gox associated with observed allocations.

The sampling adds work to the measurement; it must be configured according to the level of detail required.

Results

The output uses the tag BENCH and presents a summary of metrics. --v shows the complete structured result.

test.Save() keeps the individual JSON, while -out generate the global report. No copies of HTTP responses are saved in Benchmark mode. Results to distinguish both mechanisms.

Current limitations

The options -cpuprofile, -memprofile and -race They are not yet implemented. Their use ends with an error.

The metrics allow to observe the behavior of the pipeline, but do not replace the profiling when it is necessary to investigate the full origin of CPU or memory consumption.

Integration with Go

The runner repeats the pipeline on the GOX runtime and calculates metrics equivalent to those commonly used in Go's Benchmarks. The results are expressed by operation to facilitate the comparison between implementations.

Memory sampling uses runtime information and links the observed allocations to handlers compiled from files .gox when a location is available.

Best practices

• Check first that the functional test is correct.
• It uses enough iterations to achieve stable results.
• Set warmove when the handler has initial costs.
• Compare benchmarks executed under equivalent conditions.
• Analyzes the allocations only within routes relevant to performance.
• Do not mix results from different machines or configurations.

To know the public API available to develop applications with GOX, see the reference of the SDK.

See also

• SDK
• Actions
• Execution
• Configuration
• Results