服务器处理70个请求，每个响应时间少于50毫秒

Question

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

我已经设置tcp_tw_reuse为1 ip_local_port_range设置为1024到65535

设置为60（默认）启用TCP连接复用。

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

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

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

Answer 1

我打算出去，猜测这些是静态文件，你不通过cgi传递它们。

从我在分析和Google搜索分析方面的经验来看，它的所有关于寻找瓶颈，或优化占用时间最多的领域，并没有花费所有精力来加快占用您5％时间的流程。

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

例如，如果ping需要150ms，你的问题是你的网络，而不是你的nginx conf。 如果文件为兆字节，则不是nginx。

如果响应时间在每秒1到30次请求之间不同，我会认为比精细的nginx调整更强烈。

您能否再阐明这种情况？

- update - 我在开箱即用的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。我可能会猜测两者。

如果修复很重要，我会得到一个专用的服务器。但那只是我的知识而已。

Answer 2

由于客户端主机数量非常少，因此可能在TIME_WAIT状态下关闭的TCP连接通过预留可用端口号导致速度变慢。

也许你应该尝试：

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

注意有关该选项：

启用TIME_WAIT套接字快速回收。不推荐使用此选项，因为这会在使用NAT（网络地址转换）时导致问题 。

Answer 3

nginx的keepalive_timeout控制HTTP protocol's ability to re-use existing connections和无关与TCP TIME_WAIT状态。 （这与TCP保持活跃探测无关;这些探测在空闲时间大约两小时后发送，因此对于几乎所有事情都无用）。服务器）将重新使用现有连接请求新数据，这将节省TCP three-way handshake所需的时间。如果您的客户端和服务器可以使用它，您可能会尝试增加此超时值。

的TCP TIME_WAIT状态是有确保都同行知道死连接是死了 - 如果一方重新使用的端口时，重新连接，而另一侧错过的FIN数据包时，它可能认为来自新连接的数据包实际上是针对旧的连接。哎呀。 TIME_WAIT状态阻止了这一点。通常不需要摆弄这个数字;考虑你的客户，每秒连接70次。有63k端口可供选择，大约500秒之间的端口重新使用：63k端口/ 70 cps == 1000秒，随机选择说也许一半。 TIME_WAIT接近两分钟，这是七八分钟。当你从同行中每秒获得约100个连接时，我会开始担心更多关于TIME_WAIT的事情。

相反，我认为你遇到的问题是Nagle's algorithm，用于防止互联网被一堆愚蠢的小包过度运行。 Nagle的算法会导致TCP系统在发送少量数据时稍等一会儿，希望在等待时数据将会到达更多。一旦事情开始，这很好，但在启动连接时会导致无法接受的延迟。通常的反制Nagle的机制是设置TCP_NODELAY套接字选项。 （好吧，拨打send(2)和recv(2)调用的应用程序的模式是更好，但不总是一个选项，因此，这种创可贴。）有关详细信息，请参阅tcp(7),setsockopt(2)联机帮助页。由于Nagle的算法与TCP delayed ACK algorithm交互作用较差，因此您还可以要求TCP发送ACK数据包，而不是通常的ACK数据包的小延迟：即TCP_QUICKACK套接字选项。

tcp(7)联机帮助页还提供了一个tcp_low_latency可调参数的细微提示，它可以执行您所需的操作。尝试将其打开。 （我不知道这个决定的后果，但我的猜测会影响Nagle和Delayed ACK站点范围内的，而不是每插座选项。）