nginx 真的支持高并发么

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› NGINX

› NGINX Trac

› 3rd Party Modules

› Security Advisories

› CHANGES

› OpenResty

› ngx_lua

› Tengine

在线学习资源

› NGINX 开发从入门到精通

NGINX Modules

› ngx_echo

这是一个创建于 1492 天前的主题，其中的信息可能已经有所发展或是发生改变。

号称百万并发，但是我用 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 的并发

Nginx

并发

upstream

timed

37 条回复 • 2020-10-23 10:29:57 +08:00

wjhjd163

2020-10-22 12:01:57 +08:00 via Android

nginx 缓存爆了的情况下会写硬盘
不如你看看压测的时候硬盘读写如何?

superrichman

2020-10-22 12:06:53 +08:00 via iPhone

不走 nginx 你的服务并发是多少？

sadfQED2

2020-10-22 12:09:22 +08:00 via Android

我大学老师曾经说过，代码编译通不过先检查你代码，编译器没错。

我觉得你这个也差不多

hakono

2020-10-22 12:13:48 +08:00

upstream timed out

我怎么感觉是你上游的服务器的问题？

上有服务器压测 100K/700K 的并发是多少？

nightwitch

2020-10-22 12:26:54 +08:00

proxy_pass xxxxxx;

先对 proxy_pass 的地址来个压测看看能到多少？

Lax

2020-10-22 12:28:00 +08:00

ab 和 nginx 是同一台服务器吗？
测试时的网络带宽有没有跑满？
测试时 nginx/后端 /ab 所在机器的 cpu 利用率达到了多少？ io 利用率呢？

eason1874

2020-10-22 12:38:08 +08:00

Nginx 高并发是经过验证的，不少 CDN 厂商都在用就是例证。

缓存命中还是慢的话，我首先会怀疑硬盘 IO 然后才是其他，先去掉后端，直接用服务器本地文件压测，逐一排除。

bruceliang

2020-10-22 12:49:07 +08:00

内存搞大点

virusdefender

2020-10-22 12:54:47 +08:00

看上去你的 upstream 撑不住了

xuanbg

2020-10-22 13:06:08 +08:00

upstream {
xxxxx
keepalive 1000;
}

就这？？？不多来几台机器做负载均衡么？譬如：
upstream xxxxx {
ip_hash;
server x.y.z.1 max_fails=2 fail_timeout=60s;
server x.y.z.2 max_fails=2 fail_timeout=60s;
……
}

misaka19000

2020-10-22 13:18:11 +08:00

先把你测试的机器的配置报出来，这是最基本的

ctOS1H

2020-10-22 13:57:14 +08:00

先测 upstream 吧

lazyfighter

2020-10-22 14:07:09 +08:00

这不是拉不出屎来怪茅坑吗~

est

2020-10-22 14:11:37 +08:00 via Android

1M 的文件，怕不是楼主 1M 出口带宽爆了

Jooooooooo

2020-10-22 15:50:10 +08:00

遇到这种问题, 首先怀疑被大规模使用东西的问题肯定不行

从别的地方找原因, 都排除了再看

polymerdg

2020-10-22 15:55:14 +08:00

700K * 500
340 多 MB/S
帶寬夠用？

kiddingU

2020-10-22 15:56:28 +08:00

你的 upstream 能承受多大并发？

kokol

2020-10-22 16:03:41 +08:00

感谢大家的回答，我目前用的 8 核 8G 的配置，用的云上的虚拟机来测试，都是私有子网来测试，硬盘就配了几百 G，估计就是因硬盘 IO 的问题，我加大配置，提升 IO 再来测试一下看看

newmlp

2020-10-22 16:07:51 +08:00

地球真的是圆的吗

lvzhiqiang

2020-10-22 16:08:50 +08:00

nginx 更多的时候作为中间人，中间人转发请求效率能到上万，但是这个请求真正处理还是交给上游服务器去做，上游服务器能否处理过来才决定你网站性能。我们说 nginx 能到百万并发，是有前提的。。。IO/网络带宽 /CPU

ArJun

2020-10-22 16:21:12 +08:00

nginx 的并发毋庸置疑了吧，推荐上固态云主机好点

daimiaopeng

2020-10-22 19:38:38 +08:00

不会吧不会吧，不会真的会有人拿一台服务器处理百万的并发？？？

opengps

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

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

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

cquyf

2020-10-22 19:47:58 +08:00

技术达人啊。。。。。。。。。。。

IDAEngine

2020-10-22 20:09:11 +08:00 via iPhone

nginx 一般是作为网关，转发性能非常牛逼

dorothyREN

2020-10-22 20:12:50 +08:00

upstream 就一个，理论上你这个用了 nginx 会更慢。

reus

2020-10-22 20:59:43 +08:00

是你太菜

DoctorCat

2020-10-22 21:36:55 +08:00

确定压测机性能 ok 么？
被测试的 nginx 机器硬件配置 ok 了，看清单你系统优化没有对 fd 数量的优化？
网卡带宽交换机都很 ok ？吞吐跟得上吗？

watzds

2020-10-22 21:54:20 +08:00 via Android

这不是废话吗，大文件还能高并发，做梦呢

sampeng

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

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

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

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

sampeng

2020-10-22 21:58:51 +08:00 via iPhone

用手机打的…打字速度赶不上思考的速度…是 7 倍…不是 7 个包的速度…

sampeng

2020-10-22 22:02:27 +08:00 via iPhone

另外说一嘴。你这样用缓存。多高 io 都不够你用的…放内存映射目录再看。