nginx 真的支持高并发么

号称百万并发，但是我用 ab 压测的时候，发现如果 nginx 从后端服务获取的文件大小很大的话，响应的延迟就很高
1 、如果请求 nginx，后端就返回几个字节的信息，那么上万并发没啥问题
2 、如果请求 nginx，后端返回 100K 的信息，可能就只有 5000 并发，然后日志就有 upstream timed out 的错误，再继续增加并发的话，基本全是 upstream timed out 错误
3 、如果请求 nginx，后端返回 700K 的信息，可能就只有 500 并发，然后日志也有 upstream timed out 的错误

4 、如果 nginx 配置文件里添加了 proxy_cache 缓存的话，并发会高点，但是也只有个几千并发，而且查看日志即使缓存 HIT 命中了，响应延迟仍然很高，竟然有好几秒，无法理解，从缓存中获取数据也要这么长时间，而且并发越高，响应延迟就越高，upstream timed out 也会很多，这都没有去后端请求了，直接拿的 nginx 缓存都这么慢

以下是我 nginx 的部分配置文件：
worker_processes auto;
worker_rlimit_nofile 65536;

events {
worker_connections 45000;
accept_mutex off;
multi_accept on;
use epoll;
}
http {
include mime.types;
default_type application/octet-stream;
resolver 8.8.8.8;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$proxy_host" "$upstream_addr" '
'"$upstream_response_time" "$request_time" "$upstream_cache_status"';

access_log logs/access.log main;

sendfile on;
tcp_nopush on;
tcp_nodelay on;
types_hash_max_size 2048;

send_timeout 10s;
keepalive_timeout 65;
keepalive_requests 10000;

#gzip on;
proxy_cache_path /usr/local/openresty/nginx/cache levels=1:2 keys_zone=gcdn:10m max_size=100g inactive=10m use_temp_path=off;

upstream {
xxxxx
keepalive 1000;
}
server{

proxy_pass xxxxxx;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $upstream_host;
proxy_connect_timeout 5s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;
proxy_buffering on;
proxy_buffer_size 4k;
proxy_buffers 4 1M;
proxy_busy_buffers_size 2M;
}

linux 系统内核的修改参考的这篇文章：
https://www.jb51.net/article/157985.htm

nginx 的并发跟后端返回数据量的大小有关么，大家有做过这方面的测试么，如果后端返回的数据基本在几百 K 到 1M 的话，怎样提高 nginx 的并发

opengps

2020-10-22 19:45:34 +08:00

nginx 的用途是分流，并非直接承载压力。
楼主的测试，其实忽略了一个最根本目的：负载均衡是统一入口，让压力分散到不同的机器。后端文件大小加大必然会降低网络性能，导致测试结果下降，所以负载均衡机器本身应当具备大带宽物理优势来发挥自己的高并发支撑优势。

以我的业务为例，我之前做的 gps 系统，承载上百万设备，虽然我用的不是 nginx，但是我用的是阿里云的 slb，这个地方大同小异，我用 slb 来继续讲，最终承载百万台设备 tcp 压力的是后面那 100 多台机器，再往后还有几台缓存 ecs，再往后还有几台数据库。然后往前还有几台 web 机器提供用户
也就是说，我这个规模的系统，用了 2 个负载均衡入口，一个用来负载百万设备的 tcp 连接，一个用来负载几千压力的用户 web 服务和 api 服务

sampeng

2020-10-22 21:57:35 +08:00

100K ？ aws 是虚拟机间 10Gb 带宽。6-7 年前我明确知道阿里云之间是 500MB 带宽，因为踩过这个雷，导致线上严重故障。我算了一下…正好 100K，5000 并发左右…说明现在阿里云还是这样…那为什么 700K 并发下降这么多呢？

我推测内网就算开启巨帧是 9000 的 mtu 。700K 也要分 77 个包。100k 只要 11 个包。换而言之。在同等条件任何事情不变的情况下 700 要比 100 的速度无论如何慢 7 个包的速度。而且在到达网络瓶颈后，TCP 的包会有堵塞策略。所以 77 个包和 11 个包在拥堵网络环境下的响应时间会不一样

这是我的理解和推测。要实际抓包和看系统其他监控确认推测是否正确…