V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NGINX
NGINX Trac
3rd Party Modules
Security Advisories
CHANGES
OpenResty
ngx_lua
Tengine
在线学习资源
NGINX 开发从入门到精通
NGINX Modules
ngx_echo
kokol
V2EX  ›  NGINX

nginx 真的支持高并发么

  •  
  •   kokol · 39 天前 · 4843 次点击
    这是一个创建于 39 天前的主题,其中的信息可能已经有所发展或是发生改变。
    号称百万并发,但是我用 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 的并发
    37 条回复    2020-10-23 10:29:57 +08:00
    wjhjd163
        1
    wjhjd163   39 天前 via Android
    nginx 缓存爆了的情况下会写硬盘
    不如你看看压测的时候硬盘读写如何?
    superrichman
        2
    superrichman   39 天前 via iPhone
    不走 nginx 你的服务并发是多少?
    sadfQED2
        3
    sadfQED2   39 天前 via Android
    我大学老师曾经说过,代码编译通不过先检查你代码,编译器没错。

    我觉得你这个也差不多
    hakono
        4
    hakono   39 天前
    upstream timed out

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

    上有服务器压测 100K/700K 的并发是多少?
    nightwitch
        5
    nightwitch   39 天前
    proxy_pass xxxxxx;

    先对 proxy_pass 的地址来个压测看看能到多少?
    Lax
        6
    Lax   39 天前   ❤️ 3
    ab 和 nginx 是同一台服务器吗?
    测试时的网络带宽有没有跑满?
    测试时 nginx/后端 /ab 所在机器的 cpu 利用率达到了多少? io 利用率呢?
    eason1874
        7
    eason1874   39 天前
    Nginx 高并发是经过验证的,不少 CDN 厂商都在用就是例证。

    缓存命中还是慢的话,我首先会怀疑硬盘 IO 然后才是其他,先去掉后端,直接用服务器本地文件压测,逐一排除。
    bruceliang
        8
    bruceliang   39 天前
    内存搞大点
    virusdefender
        9
    virusdefender   39 天前
    看上去你的 upstream 撑不住了
    xuanbg
        10
    xuanbg   39 天前
    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
        11
    misaka19000   39 天前
    先把你测试的机器的配置报出来,这是最基本的
    ctOS1H
        12
    ctOS1H   39 天前
    先测 upstream 吧
    lazyfighter
        13
    lazyfighter   39 天前
    这不是拉不出屎来怪茅坑吗~
    est
        14
    est   39 天前 via Android
    1M 的文件,怕不是楼主 1M 出口带宽爆了
    Jooooooooo
        15
    Jooooooooo   39 天前
    遇到这种问题, 首先怀疑被大规模使用东西的问题肯定不行

    从别的地方找原因, 都排除了再看
    polymerdg
        16
    polymerdg   39 天前
    700K * 500
    340 多 MB/S
    帶寬夠用?
    kiddingU
        17
    kiddingU   39 天前
    你的 upstream 能承受多大并发?
    kokol
        18
    kokol   39 天前
    感谢大家的回答, 我目前用的 8 核 8G 的配置,用的云上的虚拟机来测试,都是私有子网来测试,硬盘就配了几百 G,估计就是因硬盘 IO 的问题,我加大配置,提升 IO 再来测试一下看看
    newmlp
        19
    newmlp   39 天前
    地球真的是圆的吗
    lvzhiqiang
        20
    lvzhiqiang   39 天前   ❤️ 2
    nginx 更多的时候作为中间人,中间人转发请求效率能到上万,但是这个请求真正处理还是交给上游服务器去做,上游服务器能否处理过来才决定你网站性能。 我们说 nginx 能到百万并发,是有前提的。。。IO/网络带宽 /CPU
    ArJun
        21
    ArJun   39 天前
    nginx 的并发毋庸置疑了吧,推荐上固态云主机好点
    daimiaopeng
        22
    daimiaopeng   39 天前
    不会吧不会吧,不会真的会有人拿一台服务器处理百万的并发???
    opengps
        23
    opengps   39 天前
    nginx 的用途是分流,并非直接承载压力。
    楼主的测试,其实忽略了一个最根本目的:负载均衡是统一入口,让压力分散到不同的机器。后端文件大小加大必然会降低网络性能,导致测试结果下降,所以负载均衡机器本身应当具备大带宽物理优势来发挥自己的高并发支撑优势。

    以我的业务为例,我之前做的 gps 系统,承载上百万设备,虽然我用的不是 nginx,但是我用的是阿里云的 slb,这个地方大同小异,我用 slb 来继续讲,最终承载百万台设备 tcp 压力的是后面那 100 多台机器,再往后还有几台缓存 ecs,再往后还有几台数据库。然后往前还有几台 web 机器提供用户
    也就是说,我这个规模的系统,用了 2 个负载均衡入口,一个用来负载百万设备的 tcp 连接,一个用来负载几千压力的用户 web 服务和 api 服务
    cquyf
        24
    cquyf   39 天前
    技术达人啊。。。。。。。。。。。
    IDAEngine
        25
    IDAEngine   39 天前 via iPhone
    nginx 一般是作为网关,转发性能非常牛逼
    dorothyREN
        26
    dorothyREN   39 天前
    upstream 就一个, 理论上你这个用了 nginx 会更慢。
    reus
        27
    reus   39 天前
    是你太菜
    DoctorCat
        28
    DoctorCat   39 天前
    确定压测机性能 ok 么?
    被测试的 nginx 机器硬件配置 ok 了,看清单你系统优化没有对 fd 数量的优化?
    网卡带宽交换机都很 ok ?吞吐跟得上吗?
    watzds
        29
    watzds   39 天前 via Android
    这不是废话吗,大文件还能高并发,做梦呢
    sampeng
        30
    sampeng   39 天前 via iPhone   ❤️ 2
    100K ? aws 是虚拟机间 10Gb 带宽。6-7 年前我明确知道阿里云之间是 500MB 带宽,因为踩过这个雷,导致线上严重故障。我算了一下…正好 100K,5000 并发左右…说明现在阿里云还是这样…那为什么 700K 并发下降这么多呢?


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


    这是我的理解和推测。要实际抓包和看系统其他监控确认推测是否正确…
    sampeng
        31
    sampeng   39 天前 via iPhone
    用手机打的…打字速度赶不上思考的速度…是 7 倍…不是 7 个包的速度…
    sampeng
        32
    sampeng   39 天前 via iPhone
    另外说一嘴。你这样用缓存。多高 io 都不够你用的…放内存映射目录再看。
    dddd1919
        33
    dddd1919   39 天前
    “nginx 的并发跟后端返回数据量的大小有关么”

    如果是做运维的话,真替 lz 公司捏把汗
    Tink
        34
    Tink   39 天前 via Android
    这难道不是后端服务的问题吗?提示超时了呀
    masker
        35
    masker   39 天前 via Android
    是真的蠢还是钓鱼?
    钓鱼一时爽,全家火葬×
    Vkery
        36
    Vkery   38 天前
    后端处理不了,关我 nginx 什么事
    jmxct520
        37
    jmxct520   38 天前
    你这个使用 nginx upstream 模块的方法我也是醉了,负载均衡打开。。还有记得把 gzip 打开。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1200 人在线   最高记录 5268   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 19:41 · PVG 03:41 · LAX 11:41 · JFK 14:41
    ♥ Do have faith in what you're doing.