载荷作用下1% nginx响应的主要慢度

Question

Ubuntu 14.04

apt-get install nginx apache2-utils

然后对以下内容进行vi /etc/nginx/sites-enabled/default：

server {
  listen 80 default_server;

  location / {
    return 200 "Ok";
  }
}

service nginx restart

跑步：

ab -c 500 -k -n 100000 127.0.0.1/

我得到了结果：

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%     14
  99%    489
 100%   3065 (longest request)

好的，所以我得到的大多数回复非常快(这是预料中的)，但是大约1% (近1000次请求)的响应非常慢。(0.5s - 3s)

为什么会发生这种情况？如何找到问题的根源？我猜内核/sysctl，但是如何确切地找出到底是怎么回事？

UPDATE1

我试图用ab替换siege，结果是一样的。

siege -c 500 -r 200 -b 127.0.0.1/

....
Concurrency:              240.67
Successful transactions:      100000
Failed transactions:               0
Longest transaction:            1.50
Shortest transaction:           0.00

我尝试更改nginx中的一些变量，并在每次更改并重新运行ab之后重新启动服务器。

worker_processes 10;

worker_connections 7680;

multi_accept on;

events { use select; }

events { use poll; }

events { use epoll; }

我每次都尝试调整sysctl和重新运行测试：

net.core.somaxconn=5120 # including listen directive backlog in nginx

net.core.netdev_max_backlog=5120

我将打开的文件数量提高到5000000并重新运行测试。

我尝试了一些其他的tcp拥塞控制方法，每次都重新运行测试。

sysctl -w net.ipv4.tcp_congestion_control=hybla

sysctl -w net.ipv4.tcp_congestion_control=illinois

sysctl -w net.ipv4.tcp_congestion_control=lp

sysctl -w net.ipv4.tcp_congestion_control=probe

sysctl -w net.ipv4.tcp_congestion_control=scalable

sysctl -w net.ipv4.tcp_congestion_control=vegas

sysctl -w net.ipv4.tcp_congestion_control=veno

sysctl -w net.ipv4.tcp_congestion_control=westwood

sysctl -w net.ipv4.tcp_congestion_control=yeah

我尝试了更多的sysctl vars，每次都重新运行测试。

sysctl -w net.core.rmem_max=67108864 

sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432'

sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432'

sysctl -w net.core.netdev_max_backlog=30000

sysctl -w net.ipv4.tcp_congestion_control=htcp

sysctl -w net.ipv4.tcp_mtu_probing=1

sysctl -w net.core.rmem_max=134217728 

sysctl -w net.core.wmem_max=134217728 

sysctl -w net.ipv4.tcp_rmem='4096 87380 67108864'

sysctl -w net.ipv4.tcp_wmem='4096 65536 67108864'

sysctl -w net.core.netdev_max_backlog=250000

sysctl -w net.ipv4.tcp_congestion_control=htcp

sysctl -w net.ipv4.tcp_mtu_probing=1

最后，我下载了golang并编译了服务器，并在这个基本服务器上测试了ab --一切都是一样的。

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "OK")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

go run test.go

似乎没有任何因素影响到这1%。

UPDATE2

好的，这可能与CPU饱和有关。在16芯GCE机上，效果要好得多，不那么引人注目.最初的测试是在1核数字海洋实例上进行的.

UPDATE3

是的，一定是有CPU的东西。对四核GCE无影响。(加作答覆)

Answer 1

答案似乎是-没有足够的CPU

4-核心GCE

  Percentage of the requests served within a certain time (ms)
    50%      8
    66%     12
    75%     16
    80%     17
    90%     24
    95%     28
    98%     35
    99%     41
   100%     63 (longest request)

1-核心GCE

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      4
  99%    509
 100%   3597 (longest request)