![]() | 1 wjhjd163 2020-10-22 12:01:57 +08:00 via Android nginx 缓存爆了的情况下会写硬盘 不如你看看压测的时候硬盘读写如何? |
2 superrichman 2020-10-22 12:06:53 +08:00 via iPhone 不走 nginx 你的服务并发是多少? |
![]() | 3 sadfQED2 2020-10-22 12:09:22 +08:00 via Android 我大学老师曾经说过,代码编译通不过先检查你代码,编译器没错。 我觉得你这个也差不多 |
4 hakono /div> 2020-10-22 12:13:48 +08:00 upstream timed out 我怎么感觉是你上游的服务器的问题? 上有服务器压测 100K/700K 的并发是多少? |
5 nightwitch 2020-10-22 12:26:54 +08:00 proxy_pass xxxxxx; 先对 proxy_pass 的地址来个压测看看能到多少? |
6 Lax 2020-10-22 12:28:00 +08:00 ![]() ab 和 nginx 是同一台服务器吗? 测试时的网络带宽有没有跑满? 测试时 nginx/后端 /ab 所在机器的 cpu 利用率达到了多少? io 利用率呢? |
![]() | 7 eason1874 2020-10-22 12:38:08 +08:00 Nginx 高并发是经过验证的,不少 CDN 厂商都在用就是例证。 缓存命中还是慢的话,我首先会怀疑硬盘 IO 然后才是其他,先去掉后端,直接用服务器本地文件压测,逐一排除。 |
8 bruceliang 2020-10-22 12:49:07 +08:00 内存搞大点 |
![]() | 9 virusdefender 2020-10-22 12:54:47 +08:00 看上去你的 upstream 撑不住了 |
![]() | 10 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; …… } |
![]() | 11 misaka19000 2020-10-22 13:18:11 +08:00 先把你测试的机器的配置报出来,这是最基本的 |
![]() | 12 ctOS1H 2020-10-22 13:57:14 +08:00 先测 upstream 吧 |
13 lazyfighter 2020-10-22 14:07:09 +08:00 这不是拉不出屎来怪茅坑吗~ |
![]() | 14 est 2020-10-22 14:11:37 +08:00 via Android 1M 的文件,怕不是楼主 1M 出口带宽爆了 |
15 Jooooooooo 2020-10-22 15:50:10 +08:00 遇到这种问题, 首先怀疑被大规模使用东西的问题肯定不行 从别的地方找原因, 都排除了再看 |
16 polymerdg 2020-10-22 15:55:14 +08:00 700K * 500 340 多 MB/S 用? |
17 kiddingU 2020-10-22 15:56:28 +08:00 你的 upstream 能承受多大并发? |
![]() | 18 kokol OP 感谢大家的回答, 我目前用的 8 核 8G 的配置,用的云上的虚拟机来测试,都是私有子网来测试,硬盘就配了几百 G,估计就是因硬盘 IO 的问题,我加大配置,提升 IO 再来测试一下看看 |
![]() | 19 newmlp 2020-10-22 16:07:51 +08:00 地球真的是圆的吗 |
![]() | 20 lvzhiqiang 2020-10-22 16:08:50 +08:00 ![]() nginx 更多的时候作为中间人,中间人转发请求效率能到上万,但是这个请求真正处理还是交给上游服务器去做,上游服务器能否处理过来才决定你网站性能。 我们说 nginx 能到百万并发,是有前提的。。。IO/网络带宽 /CPU |
![]() | 21 ArJun 2020-10-22 16:21:12 +08:00 nginx 的并发毋庸置疑了吧,推荐上固态云主机好点 |
![]() | 22 labubu 2020-10-22 19:38:38 +08:00 不会吧不会吧,不会真的会有人拿一台服务器处理百万的并发??? |
![]() | 23 opengps 2020-10-22 19:45:34 +08:00 nginx 的用途是分流,并非直接承载压力。 楼主的测试,其实忽略了一个最根本目的:负载均衡是统一入口,让压力分散到不同的机器。后端文件大小加大必然会降低网络性能,导致测试结果下降,所以负载均衡机器本身应当具备大带宽物理优势来发挥自己的高并发支撑优势。 以我的业务为例,我之前做的 gps 系统,承载上百万设备,虽然我用的不是 nginx,但是我用的是阿里云的 slb,这个地方大同小异,我用 slb 来继续讲,最终承载百万台设备 tcp 压力的是后面那 100 多台机器,再往后还有几台缓存 ecs,再往后还有几台数据库。然后往前还有几台 web 机器提供用户 也就是说,我这个规模的系统,用了 2 个负载均衡入口,一个用来负载百万设备的 tcp 连接,一个用来负载几千压力的用户 web 服务和 api 服务 |
![]() | 24 cquyf 2020-10-22 19:47:58 +08:00 技术达人啊。。。。。。。。。。。 |
![]() | 25 IDAEngine 2020-10-22 20:09:11 +08:00 via iPhone nginx 一般是作为网关,转发性能非常牛逼 |
26 dorothyREN 2020-10-22 20:12:50 +08:00 upstream 就一个, 理论上你这个用了 nginx 会更慢。 |
27 reus 2020-10-22 20:59:43 +08:00 是你太菜 |
![]() | 28 DoctorCat 2020-10-22 21:36:55 +08:00 确定压测机性能 ok 么? 被测试的 nginx 机器硬件配置 ok 了,看清单你系统优化没有对 fd 数量的优化? 网卡带宽交换机都很 ok ?吞吐跟得上吗? |
![]() | 29 watzds 2020-10-22 21:54:20 +08:00 via Android 这不是废话吗,大文件还能高并发,做梦呢 |
30 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 个包在拥堵网络环境下的响应时间会不一样 这是我的理解和推测。要实际抓包和看系统其他监控确认推测是否正确… |
31 sampeng 2020-10-22 21:58:51 +08:00 via iPhone 用手机打的…打字速度赶不上思考的速度…是 7 倍…不是 7 个包的速度… |
32 sampeng 2020-10-22 22:02:27 +08:00 via iPhone 另外说一嘴。你这样用缓存。多高 io 都不够你用的…放内存映射目录再看。 |
33 dddd1919 2020-10-22 23:01:39 +08:00 “nginx 的并发跟后端返回数据量的大小有关么” 如果是做运维的话,真替 lz 公司捏把汗 |
![]() | 34 Tink PRO 这难道不是后端服务的问题吗?提示超时了呀 |
![]() | 35 masker 2020-10-22 23:46:56 +08:00 via Android 是真的蠢还是钓鱼? 钓鱼一时爽,全家火葬× |
36 Vkery 2020-10-23 10:16:14 +08:00 后端处理不了,关我 nginx 什么事 |
37 jmxct520 2020-10-23 10:29:57 +08:00 你这个使用 nginx upstream 模块的方法我也是醉了,负载均衡打开。。还有记得把 gzip 打开。 |