aosp12/system/netd/tests/benchmarks
hcl 7be3fd486c init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00
..
Android.bp init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00
README.md init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00
bpf_benchmark.cpp init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00
connect_benchmark.cpp init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00
dns_benchmark.cpp init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00
main.cpp init from android-12.1.0_r8 2023-01-09 17:11:35 +08:00

README.md

NetD benchmarks

These are benchmarks for libc connect and gethostbyname functions as hooked by netd.

Infrastructure

The benchmarks are powered by google-benchmark, which records four statistics:

Statistic Meaning
real_time Mean wall-clock time taken for each iteration of the function under test to complete. This includes any time spent in other processes.

Some of the **connect** benchmarks override this by implementing their own timings, but the semantics are roughly the same. See connect_benchmark.cpp for details.

cpu_time Mean time spent in the current thread during each iteration of the function under test. This does not include any time spent in other processes or blocking on I/O.

Since almost all of the functionality we are testing here is in the netd server, not the client, these timings are not relevant and should be ignored for most purposes.

iterations The number of runs of the test function that were executed, across all threads, in order for the test to reach the minimum amount of time run. Most tests here define 'minimum time run' in terms of real time or 'manual time', rather than CPU time, for the reasons above.

This should be roughly inversely proportional to **real_time** for single-threaded benchmarks and also somewhat proportional to the number of threads used.

label Field that the benchmark can fill with an arbitrary string.

For graphing purposes, a few of the benchmarks in this directory store the 90th-percentile latency in this field for comparison against the mean latency (it's only possible to plot one other value apart from mean).

If the graphing ecosystem ever becomes advanced enough to plot multiple outputs from one label, it might be more useful to log every decile to get a better picture of how spiky things are.

Methods currently being benchmarked

connect()

getaddrinfo()