去HTTP服务器测试AB vs WRK结果差异很大 [英] Go HTTP server testing ab vs wrk so much difference in result
问题描述
我试图查看go HTTP服务器可以在我的机器上处理多少个请求，所以我尝试进行一些测试，但是差异如此之大，以至于我感到困惑.
I am trying to see how many requests the go HTTP server can handle on my machine so I try to do some test but the difference is so large that I am confused.
首先，我尝试使用ab进行测试并运行此命令
First I try to bench with ab and run this command
$ ab -n 100000 -c 1000 http://127.0.0.1/
执行1000个并发请求.
Doing 1000 concurrent requests.
结果如下:
Concurrency Level: 1000
Time taken for tests: 12.055 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 12800000 bytes
HTML transferred: 1100000 bytes
Requests per second: 8295.15 [#/sec] (mean)
Time per request: 120.552 [ms] (mean)
Time per request: 0.121 [ms] (mean, across all concurrent requests)
Transfer rate: 1036.89 [Kbytes/sec] received
每秒8295个请求，这似乎是合理的.
8295 requests per second which seems reasonable.
但是然后我尝试使用以下命令在wrk上运行它:
But then I try to run it on wrk with this command:
$ wrk -t1 -c1000 -d5s http://127.0.0.1:80/
我得到这些结果:
Running 5s test @ http://127.0.0.1:80/
1 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 18.92ms 13.38ms 234.65ms 94.89%
Req/Sec 27.03k 1.43k 29.73k 63.27%
136475 requests in 5.10s, 16.66MB read
Requests/sec: 26767.50
Transfer/sec: 3.27MB
每秒26767个请求?我不明白为什么会有如此大的差异.
26767 requests per second? I don't understand why there is such a huge difference.
运行的代码是最简单的Go服务器
The code run was the simplest Go server
package main
import (
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
w.Write([]byte("Hello World"))
})
http.ListenAndServe(":80", nil)
}
我的目标是在增加内核时查看go服务器可以处理多少个请求，但这在我什至开始增加CPU能力之前就相差太大了.有谁知道Go服务器在添加更多内核时如何扩展?还有为什么ab和wrk之间的巨大差异?
My goal is to see how many requests the go server can handle as I increase the cores, but this is just too much of a difference before I even start adding more CPU power. Does anyone know how the Go server scales when adding more cores? And also why the huge difference between ab and wrk?
推荐答案
首先:基准测试通常是虚假的.一旦开始添加数据库调用，模板渲染，会话解析等(期望数量级的差异)，发回少量字节将使您非常获得不同的结果.
Firstly: benchmarks are often pretty artificial. Sending back a handful of bytes is going to net you very different results once you start adding database calls, template rendering, session parsing, etc. (expect an order of magnitude difference)
然后解决本地问题-开发机器与生产之间的开放文件/套接字限制，基准测试工具(ab/wrk)和Go服务器在这些资源，本地环回适配器或OS TCP堆栈(以及TCP堆栈调整)，等等.
Then tack on local issues - open file/socket limits on your dev machine vs. production, competition between your benchmarking tool (ab/wrk) and your Go server for those resources, the local loopback adapter or OS TCP stacks (and TCP stack tuning), etc. It goes on!
此外:
-
ab未被高度重视 - 仅HTTP/1.0，因此不执行keepalive
- 您的其他指标差异很大-例如查看每种工具报告的平均延迟-Ab的延迟要高得多
- 您的
ab测试也可以运行12s，而不是您的wrk测试的5s. - 即使8k req/s也是巨大的负载-每小时有28个百万请求.即使在进行数据库调用，整理JSON结构等之后降至3k/req/s，您仍然能够处理大量负载.尽早在这类基准测试中不要太束缚.
abis not highly regarded- It is HTTP/1.0 only, and therefore doesn't do keepalives
- Your other metrics vary wildly - e.g. look at the avg latency reported by each tool - ab has a much higher latency
- Your
abtest also runs for12sand not the5syour wrk test does. - Even 8k req/s is a huge amount of load - that's 28 million requests an hour. Even if—after making a DB call, marshalling a JSON struct, etc—that went down to 3k/req/s you'd still be able to handle significant amounts of load. Don't get too tied up in these kind of benchmarks this early.
我不知道您使用的是哪种机器，但是我的配备3.5GHz i7-4771的iMac可以在单线程上以w.Write([]byte("Hello World\n"))
I have no idea what kind of machine you're on, but my iMac with a 3.5GHz i7-4771 can push upwards of 64k req/s on a single thread responding with a w.Write([]byte("Hello World\n"))
简短的答案:使用wrk并记住基准测试工具存在很大差异.
Short answer: use wrk and keep in mind that benchmarking tools have a lot of variance.
这篇关于去HTTP服务器测试AB vs WRK结果差异很大的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
