go-ipam
go-ipam copied to clipboard
Benchmark acquirespecificip to nail down performance problems
#146 shows that ip allocation in prefixes with a lot of already allocated ips is slow.
This PR implements a Benchmark which shows this clearly:
go test -benchmem -run=^$ -tags integration,client -memprofile memprofile.out -cpuprofile profile.out -bench ^BenchmarkAcquireSpecificIPInternal$ github.com/metal-stack/go-ipam
Using postgres:16-alpine cockroach:latest-v23.1 redis:7.2-alpine keydb:latest etcd:v3.5.10 mongodb:7
goos: linux
goarch: amd64
pkg: github.com/metal-stack/go-ipam
cpu: 12th Gen Intel(R) Core(TM) i7-1260P
BenchmarkAcquireSpecificIPInternal/empty_prefix-16 10000 746019 ns/op 461410 B/op 5024 allocs/op
BenchmarkAcquireSpecificIPInternal/hundert_ips_allocated-16 10000 766130 ns/op 469745 B/op 5125 allocs/op
BenchmarkAcquireSpecificIPInternal/thousand_ips_allocated-16 3232 404067 ns/op 266595 B/op 2790 allocs/op
BenchmarkAcquireSpecificIPInternal/two_thousand_ips_allocated-16 1892 616107 ns/op 381988 B/op 4035 allocs/op
BenchmarkAcquireSpecificIPInternal/five_thousand_ips_allocated-16 1 1819201577 ns/op 1182815640 B/op 12581364 allocs/op
PASS
looking at the cpu profile, we can see that most of the time is spent in the deepcopy function of a prefix.
This is the cpu profile running this benchmark with an empty prefix:
And this shows the cpu profile with 5000 already allocated ips:
Graphs are generated with:
o tool pprof profile.out
File: go-ipam.test
Type: cpu
Time: May 11, 2024 at 9:41am (CEST)
Duration: 23.68s, Total samples = 27.24s (115.04%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) web