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）
为什么发生这种情况？ 如何find问题的根源？ 我猜测内核/ sysctl，但如何找出究竟是什么？
UPDATE1
我试图用siege取代ab ，结果是一样的。
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更改一些variables，并在每次更改后重新启动服务器，然后重新运行ab 。
worker_processes 10; worker_connections 7680; multi_accept on; events { use select; } events { use poll; } events { use epoll; }
我试着每次调整sysctl并重新运行testing：
net.core.somaxconn=5120 # including listen directive backlog in nginx net.core.netdev_max_backlog=5120
我提出了一些打开的文件到5000000，并重新运行testing。
我尝试了一些其他的TCP拥塞控制方法，并且每次都重新运行testing。
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
我尝试了更多的sysctlvariables，并且每次都重新运行testing。
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并编译了服务器，并testing了这个基本服务器上的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机器上，效果好得多，不太明显。 最初的testing是在1核数字海洋实例上完成的。
UPDATE3
是的，必须与CPU的东西。 对4核GCE没有影响。 （添加为答案）
看来答案是 – 没有足够的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)