1

我收到来自附近服务器的有限数量的 IP（< 4）的大量 http GET 请求。任务是保持每个请求的响应时间 <= 50 毫秒。

我通过设置tcp_tw_reuse为 1启用了 TCP 连接重用。ip_local_port_range设置为 1024 到 65535。

tcp_fin_timeout设置为 60（默认值）。

在我的网络服务器 conf 文件（nginx）中，我将 keepalive_timeout 设置为 5（这是否与 tcp 相关TIME_WAIT？）。

现在，我每秒收到 5 个请求，响应时间约为 200 毫秒。

我需要帮助来对我的响应时间进行一些重大改进（本地计算时间可以忽略不计）。

4

3 回答 3

3

我要出去猜测这些是静态文件，而您没有通过 cgi 传递它们。

根据我在分析和谷歌分析方面的经验，这一切都是为了找到瓶颈，或者优化花费最多时间的区域，而不是花费你所有的精力来加速需要 5% 时间的过程。

我想知道更多关于你的设置。一个文件的响应时间是多少？ping 的回程时间是多少？文件有多大？

例如，如果 ping 需要 150 毫秒，那么您的问题是您的网络，而不是您的 nginx 配置。如果文件以兆字节为单位，则它不是 nginx。

如果响应时间在每秒 1 到 30 个请求之间不同，我会假设比更精细的 nginx 调整更激烈。

您能否进一步说明情况？

-- 更新 -- 我在开箱即用的 nginx 服务器上做了一个基准测试，得到一个典型的 index.php 页面。

从服务器内部进行基准测试时：

roderick@anon-webserver:~$ ab -r -n 1000 -c 100 http://anon.com/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking anon.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/0.8.54
Server Hostname:        anon.com
Server Port:            80

Document Path:          /index.php
Document Length:        185 bytes

Concurrency Level:      100
Time taken for tests:   0.923 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      380000 bytes
HTML transferred:       185000 bytes
Requests per second:    1083.19 [#/sec] (mean)
Time per request:       92.320 [ms] (mean)
Time per request:       0.923 [ms] (mean, across all concurrent requests)
Transfer rate:          401.96 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.6      4       9
Processing:     1   43 147.6      4     833
Waiting:        1   41 144.4      3     833
Total:          4   47 148.4      8     842

Percentage of the requests served within a certain time (ms)
  50%      8
  66%      8
  75%      9
  80%      9
  90%     13
  95%    443
  98%    653
  99%    654
 100%    842 (longest request)

从我的家庭桌面进行基准测试时：

roderick@Rod-Dev:~$ ab -r -n 1000 -c 100 http://anon.com/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking anon.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/0.8.54
Server Hostname:        anon.com
Server Port:            80

Document Path:          /index.php
Document Length:        185 bytes

Concurrency Level:      100
Time taken for tests:   6.391 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      380000 bytes
HTML transferred:       185000 bytes
Requests per second:    156.48 [#/sec] (mean)
Time per request:       639.063 [ms] (mean)
Time per request:       6.391 [ms] (mean, across all concurrent requests)
Transfer rate:          58.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       40  260 606.9    137    3175
Processing:    81  214 221.7    140    3028
Waiting:       81  214 221.6    140    3028
Total:        120  474 688.5    277    6171

Percentage of the requests served within a certain time (ms)
  50%    277
  66%    308
  75%    316
  80%    322
  90%    753
  95%    867
  98%   3327
  99%   3729
 100%   6171 (longest request)

我的操作系统是 linux，我的 cpu 已经使用了 3 年（这是一台 500 美元的服务器）。

我对配置文件没有做任何事情。

这告诉我什么？nginx 不是问题。

您的服务器网络崩溃或 AWS 限制了您的 CPU。我可能会猜到两者。

如果修复如此重要，我会得到一个专用服务器。但这只是据我所知。

于 2012-02-13T12:06:45.917 回答
2

nginx'skeepalive_timeout控制HTTP 协议重用现有连接的能力，与 TCP TIME_WAIT状态无关。（它也与 TCP keep-alive 探测无关；这些探测是在大约两个小时的空闲时间后发送的，因此几乎对所有事情都无用。）

HTTP1.1 客户端和服务器（以及 HTTP1.0 客户端和服务器的某些组合）将重用现有连接来请求新数据，这将节省TCP 三向握手所需的时间。如果您的客户端和服务器可以使用它，您可能希望尝试增加此超时值。

TCP TIME_WAIT 状态是为了确保双方都知道死连接已经死——如果在重新连接时一方重新使用端口而另一方错过了 FIN 数据包，它可能会认为来自新连接的数据包是实际上对于旧连接。哎呀。TIME_WAIT 状态可以防止这种情况。一般不需要摆弄这个数字；考虑您的客户，每秒连接 70 次。有 63k 端口可供选择，端口重用之间大约需要 500 秒：63k 端口 / 70 cps == 1000 秒，随机选择可能只有一半。TIME_WAIT 接近两分钟，这个是七八分钟。当您每秒从对等点获得大约 100 个连接时，我会开始更加担心 TIME_WAIT。

相反，我认为您遇到的问题是Nagle 的算法，用于防止 Internet 被一堆愚蠢的小数据包过度运行。Nagle 的算法使 TCP 系统在发送少量数据时等待一小段时间，以期在等待期间有更多数据到达。一旦事情开始，这非常好，但在启动连接时可能会导致不可接受的延迟。对付 Nagle 的常用机制是设置TCP_NODELAY套接字选项。（好吧，摆弄应用程序的send(2)和recv(2)调用模式更好，但并不总是一种选择。因此，这个创可贴。）有关详细信息，请参阅tcp(7)手册setsockopt(2)页。由于 Nagle 算法与TCP 延迟 ACK 算法，您也可以要求 TCP立即发送ACK 数据包，而不是通常对 ACK 数据包的小延迟：这是TCP_QUICKACK套接字选项。

联机帮助页还提供了有关可能满足您需要的可调参数的tcp(7)轻微提示。tcp_low_latency尝试打开它。（我不知道这个决定的后果，但我的猜测会影响 Nagle 和延迟 ACK 站点范围，而不是每个套接字选项。）

于 2012-02-14T03:49:56.153 回答
0

由于客户端主机太少，可能在 TIME_WAIT 状态下关闭的 TCP 连接会通过保留可用端口号导致速度变慢。

也许你应该尝试：

echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

关于选项的注意事项：

启用 TIME_WAIT 套接字的快速回收。不建议启用此选项，因为这会在使用 NAT（网络地址转换）时引起问题。

于 2012-02-13T12:12:03.030 回答