Bug#943733: RFP: golang-bombardier -- Fast cross-platform HTTP benchmarking tool written in Go
Package: wnpp
Severity: wishlist
* Package name : golang-bombardier
Version : 1.2.4
Upstream Author : Максим Федосеев
* URL : https://github.com/codesenberg/bombardier
* License : MIT/X
Programming Lang: Golang
Description : Fast cross-platform HTTP benchmarking tool written in Go
bombardier is a HTTP(S) benchmarking tool. It is written in Go
programming language and uses excellent fasthttp instead of Go's
default http library, because of its lightning fast performance.
With bombardier v1.1 and higher you can now use net/http client if you
need to test HTTP/2.x services or want to use a more RFC-compliant
HTTP client.
====
There are many HTTP benchmarking tools in Debian, but many suffer from
significant bitrot. Tools like `siege` or `ab` (part fo apache2-utils)
do not support HTTP/2, for example. Both of those also suffer from
significant performance limitations when compared to bombardier. A
simple benchmark of the three, for example, shows bombardier performs
much better on a minimalist Hetzner virtual machine (CX11):
Siege:
root@cache-02:~# siege
** SIEGE 4.0.4
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions: 28895 hits
Availability: 100.00 %
Elapsed time: 119.73 secs
Data transferred: 285.18 MB
Response time: 0.40 secs
Transaction rate: 241.33 trans/sec
Throughput: 2.38 MB/sec
Concurrency: 96.77
Successful transactions: 28895
Failed transactions: 0
Longest transaction: 1.26
Shortest transaction: 0.05
Load went to about 2 (`Load average: 1.65 0.80 0.36` after test), with
one CPU constantly busy and the other at about 50%, memory usage was
low (~800M).
ab:
# ab -c 100 -n 1000 https://blog.torproject.org/
[...]
Server Software: ATS/8.0.2
Server Hostname: blog.torproject.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,4096,256
Server Temp Key: X25519 253 bits
TLS Server Name: blog.torproject.org
Document Path: /
Document Length: 53320 bytes
Concurrency Level: 100
Time taken for tests: 4.010 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 54421000 bytes
HTML transferred: 53320000 bytes
Requests per second: 249.37 [#/sec] (mean)
Time per request: 401.013 [ms] (mean)
Time per request: 4.010 [ms] (mean, across all concurrent requests)
Transfer rate: 13252.82 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 23 254 150.0 303 549
Processing: 14 119 89.3 122 361
Waiting: 5 105 89.7 105 356
Total: 37 373 214.9 464 738
Percentage of the requests served within a certain time (ms)
50% 464
66% 515
75% 549
80% 566
90% 600
95% 633
98% 659
99% 675
100% 738 (longest request)
Bombardier results are much better and pretty much max out the gigabit
connexion:
$ ./go/bin/bombardier --duration=2m --latencies https://blog.torproject.org/
Bombarding https://blog.torproject.org:443/ for 2m0s using 125 connection(s)
[=========================================================================] 2m0s
Done!
Statistics Avg Stdev Max
Reqs/sec 2021.18 572.50 5462.41
Latency 62.82ms 22.98ms 1.62s
Latency Distribution
50% 60.43ms
75% 69.43ms
90% 80.59ms
95% 91.31ms
99% 156.62ms
HTTP codes:
1xx - 0, 2xx - 238797, 3xx - 0, 4xx - 0, 5xx - 0
others - 0
Throughput: 103.73MB/s
It might be because it supports doing HTTP/2 requests and, indeed, the
`Throughput` drops down to `14MB/s` when we use the `--http1` flag,
along with rates closer to ab:
anarcat@cache-02:~$ ./go/bin/bombardier --duration=2m --latencies https://blog.torproject.org/ --http1
Bombarding https://blog.torproject.org:443/ for 2m0s using 125 connection(s)
[=========================================================================] 2m0s
Done!
Statistics Avg Stdev Max
Reqs/sec 1320.90 200.04 1820.33
Latency 96.15ms 21.39ms 671.40ms
Latency Distribution
50% 92.86ms
75% 104.60ms
90% 118.41ms
95% 128.01ms
99% 160.40ms
HTTP codes:
1xx - 0, 2xx - 156265, 3xx - 0, 4xx - 0, 5xx - 0
others - 0
Throughput: 14.49MB/s
So I think this would be a great addition to Debian.
Upstream's package name is "bombardier" which, unfortunately, conflict
with the "bombardier" source package already present in Debian. I
suggest the "bombardier-go" source (and binary?) package,
I would also suggest that the binary package ships a `bombardier`
commandline package and conflict with the `bombardier` package. I
don't see both packages being usefully installed at once, but I could
be convinced otherwise.
Not sure how else to handle this conflict. The source package, at
least, could be named like other golang packages, with the mouthful of
golang-github-codesenberg-bombardier, but I think the binary package
should still be more meaningful, hence bombardier-go.
Other ideas:
golang-bombardier
go-bombardier
bombardier-bench
bombardier-http
?
Reply to: