为什么我的Hello World Go服务器会被ApacheBench压垮?

huangapple go评论80阅读模式
英文:

Why is my Hello World go server getting crushed by ApacheBench?

问题

package main

import (
	"io"
	"net/http"
)

func hello(w http.ResponseWriter, r *http.Request) {
	io.WriteString(w, "Hello world!\n")
}

func main() {
	http.HandleFunc("/", hello)
	http.ListenAndServe(":8000", nil)
}

我有几个非常基本的HTTP服务器,它们都出现了这个问题。

$ ab -c 1000 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
apr_socket_recv: Connection refused (61)
Total of 5112 requests completed

使用较小的并发值,情况仍然不好。对我来说,问题通常在5000-6000次请求左右出现:

$ ab -c 10 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6277 requests completed

实际上,即使完全取消并发,问题仍然(有时)会发生:

$ ab -c 1 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6278 requests completed

我不禁想知道是否达到了某种操作系统限制?我该如何判断?我该如何缓解这个问题?

英文:
package main

import (
	&quot;io&quot;
	&quot;net/http&quot;
)

func hello(w http.ResponseWriter, r *http.Request) {
	io.WriteString(w, &quot;Hello world!\n&quot;)
}

func main() {
	http.HandleFunc(&quot;/&quot;, hello)
	http.ListenAndServe(&quot;:8000&quot;, nil)
}

I've got a couple of incredibly basic HTTP servers, and all of them are exhibiting this problem.

$ ab -c 1000 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 &lt;$Revision: 1604373 $&gt;
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
apr_socket_recv: Connection refused (61)
Total of 5112 requests completed

With a smaller concurrency value, things still fall over. For me, the issue seems to show up around the 5k-6k mark usually:

$ ab -c 10 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 &lt;$Revision: 1604373 $&gt;
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6277 requests completed

And in fact, you can drop concurrency entirely and the problem still (sometimes) happens:

$ ab -c 1 -n 10000 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 &lt;$Revision: 1604373 $&gt;
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
apr_socket_recv: Operation timed out (60)
Total of 6278 requests completed

I can't help but wonder if I'm hitting some kind of operating system limit somewhere? How would I tell? And how would I mitigate?

答案1

得分: 51

简而言之,你的端口用尽了。

在OSX上,默认的临时端口范围是49152-65535,只有16,383个端口。由于每个ab请求都是http/1.0(在你的第一个示例中没有keepalive),每个新请求都会占用一个端口。

每个端口被使用后,它会被放入一个队列中,等待TCP的“最大段寿命”(在OSX上配置为15秒)。因此,如果在15秒内使用超过16,383个端口,你将受到操作系统对进一步连接的限制。根据哪个进程首先用尽了端口,你将从服务器端收到连接错误或者ab的挂起。

你可以通过使用支持http/1.1的负载生成器(如wrk)或者使用ab的keepalive(-k选项)来缓解这个问题,这样连接将根据工具的并发设置进行重用。

现在,你正在对服务器代码进行基准测试,但是负载生成器和本地操作系统以及网络堆栈的负担可能与服务器本身一样大。如果你想对一个HTTP服务器进行基准测试,最好从多个不在同一台机器上运行的客户端进行一些有意义的工作。

英文:

In short, you're running out of ports.

The default ephemeral port range on osx is 49152-65535, which is only 16,383 ports. Since each ab request is http/1.0 (without keepalive in your first examples), each new request takes another port.

As each port is used, it get's put into a queue where it waits for the tcp "Maximum Segment Lifetime", which is configured to be 15 seconds on osx. So if you use more than 16,383 ports in 15 seconds, you're effectively going to get throttled by the OS on further connections. Depending on which process runs out of ports first, you will get connection errors from the server, or hangs from ab.

You can mitigate this by using an http/1.1 capable load generator like wrk, or using the keepalive (-k) option for ab, so that connections are reused based on the tool's concurrency settings.

Now, the server code you're benchmarking does so little, that the load generator is being taxed just as much as the sever itself, with the local os and network stack likely making a good contribution. If you want to benchmark an http server, it's better to do some meaningful work from multiple clients not running on the same machine.

huangapple
  • 本文由 发表于 2015年5月20日 22:32:05
  • 转载请务必保留本文链接:https://go.coder-hub.com/30352725.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定