Changes to code in the RPC path can cause unexpected performance regressions. For example, embedding a struct as a pointer can lead to extra allocations, degrading garbage collection performance. To prevent this, we should run benchmarks on every pull request to compare performance against the master branch and flag any regressions."
gRPC C++ has a script that does a similar check and adds PR labels.
Some example commands to run unary and streaming performance benchmarks.
# unary
go run benchmark/benchmain/main.go -benchtime=60s -workloads=unary \
-compression=off -maxConcurrentCalls=500 -trace=off \
-reqSizeBytes=100 -respSizeBytes=100 -networkMode=Local -resultFile="${RUN_NAME}" -recvBufferPool=simple
go run benchmark/benchresult/main.go unary-before unary-after
# streaming
go run benchmark/benchmain/main.go -benchtime=60s -workloads=streaming \
-compression=off -maxConcurrentCalls=500 -trace=off \
-reqSizeBytes=100 -respSizeBytes=100 -networkMode=Local -resultFile="${RUN_NAME}" -recvBufferPool=simple
Changes to code in the RPC path can cause unexpected performance regressions. For example, embedding a struct as a pointer can lead to extra allocations, degrading garbage collection performance. To prevent this, we should run benchmarks on every pull request to compare performance against the master branch and flag any regressions."
gRPC C++ has a script that does a similar check and adds PR labels.
Some example commands to run unary and streaming performance benchmarks.