遇到真正的高并发问题了，特来求助

[abcbuzhiming]

以前做的项目，要么服务器够多，要么访问量比较分散，一天虽然人多，但是都是不同时段。所以没遭遇到访问瓶颈。这次真刀真枪的需要进行一次单服优化，然后就发现单服性能不可思议的低。大致情况如下：
应用服务器是 Tomcat，在阿里云上的 4 核心的 xero，8GB 内存，10MB 带宽，技术实现是 spring mvc，并不是特别复杂的计算业务，说难听点仅仅是 crud，而且输出的是纯粹的 json，没有其它的静态文件之类的东西。然后 MySQL 数据库在和应用服务器同一区域的另外一台阿里云服务器上，类似的配置，4 核心，8GB 内存，用的是高效 SSD。
这样的两台(一组)服务器，能抗住多少并发呢，500 不到。。。

然后开始初步分析，发现一个问题，就是哪怕是单纯的数据库读业务，从浏览器请求到服务器，服务器从数据库读取完毕到返回给前端，最快也要 20-30ms 左右，稍微复杂点的数据结构就上 100ms 了，如果按这个计算，每秒每个线程的处理能力理论最快也就 50 个并发请求，4 核心的机器上，JVM 的线程池一般也就核心的 1.5-2 倍，顶多不到 10 个线程，这样一算，单服理论并发处理能力确实只有 500 不到。。。

我不死心于是回头去找以前的类似服务器做测试，结果发现性能是类似的，只不过当年是靠着服务器够多顶住了罢了。

我知道肯定会有人说，上缓存啊，我当然知道上缓存，我的困惑是，难道只有上缓存一条路，那些并发上 w 的都是靠缓存顶住的吗？不上缓存的话，我现在服务器的性能指标到底是否正常？

[misaka19000]

@ittianyu #5。。。不知道你做过多大的并发数？ 500 已经不低了

[tachikomachann]

mark
4c8g 两台机器，500 并发的话，算挺高了。

[best1a]

并发和 QPS 是两个不同的概念...

[lolizeppelin]

不写 java 但是楼上提到的 100m 带宽的解决方向是没错的

你们用虚拟机还是要了解下云服务器的网络和存储架构的

老在代码和自己的服务器上找问题很可能是找不到结果的

[neoblackcap]

@jokerlee @tcsky 这样我觉得其实架构师需要背锅了。出来久了，面试多，项目做多了，我觉得一个合格的架构师的确是需要预估业务量的。然后选择合适的架构。以前还好觉得很多项目都很容易做烂，不过我现在觉得，刚开始选一个性能高一些的架构的确是好事。开发效率其实可以从外部库来提升的。比如现在基于 openresty 的东西他们的性能都不差，业务写起来其实跟其他的框架也不会差到哪里去。
因为以前自己也干过无脑加线程的事情，但是业务高上去的话，的确解决不了。自己后来也反省，并发这事情啊其实跟 IO 密不可分，比较好解决的一个就是用户态线程(erlang, golang)，二就是 IO 复用+非堵塞 IO+线程池即 one thread one loop + 线程池的架构。
无脑加线程的确可以解决一部分问题，但是假如业务是往上走的话，很快就会出问题的。因为单纯地加线程跟规模不是线性的关系。

[hcymk2]

https://www.techempower.com/benchmarks/#section=data-r16&hw=cl&test=query&f=zijunz-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-zik0zj-4zsov
D3v2 是 4 核,RAM 14GiB 的实列
1,566 Responses per second

[xiaoshenke]

@ittianyu 别人嘲讽你是因为，真实的线上环境不是只有单次 crud 的简单业务场景，而是比如有多层调用，甚至调用那种有时候几秒才能响应的第三方服务的真实复杂场景，在这种情况下，500 并发已经是非常高了。

[sampeng]

都扯了一些有的没得。都很有道理。500 并发不低。但单机真的也谈不上特别高。但这个看和什么比。所有性能对比是要有参照物的

有几个问题 lz 没有交代
这个性能瓶颈你是怎么得到的，是 500tps 左右接口开始打不开？
请先做基准测试。同样项目框架，连数据库，随便查一条，输出 json。每一步算一个测试用例。这就是你的基准测试了。哪一步有问题，问题就出在哪。正常情况是基准测试效率都在可接受范围内。

其次，用测试工具测试，所谓评价一定是响应时间是个慢慢变大的过程。如果延迟一直没变化，但是接口打不开了。那问题在你的容器开始拒绝新的连接。和其他都无关。


查性能问题，我的经验就是控制变量，一个一个查。很好查的。lz 的用例还算简单。应该不难。

曾经更多次查一些无法控制变量的性能问题才叫噩梦

[luozic]

基准 benckmark 撸上几把，研究一下瓶颈。 实际不上缓存 nginx+lua 可以搞到 5000qps 单机

[xiaoshenke]

楼主对于线程的理解…我只能说你大概是运维吧。对于 io 密集型的业务场景，你等一个 io 可能是 ms 级别的时间，相比之下切换线程带来的损耗微乎其微。如果是 cpu 密集型的，确实加线程反而因为增加切换上下文而不会有效果

[sampeng]

看了楼下回复，资源还没用就不响应了。这可能就是我说的，逻辑处理很快，但是拒绝新的连接进来。

经验里，几个可能。
1，linux 内核问题，tcp 用完，文件句柄用完了。看看最高的时候 socke 数是多少？ ss -s ？
2，和 linux 类似，是 mysql 拒绝新连接。也就是 mysql 连接池。java 一般 redis 和 mysql 都是连接池。可以试试放大一倍。
3，java 容器拒绝，线程池就那么大。新的连接进来被等待。

[jokerlee]

@neoblackcap 我就这么说吧 国内大厂 java 的业务层就没有大规模应用非阻塞模型的，原因是完全的非阻塞模型带来的性能提升一般也就是 20%，而开发难度的提升一倍都不止

应用层和中间件的技术选型考量是不一样的，应用层要兼顾开发效率，你当然可以说去用 openresty nidejs go 之类原生支持非阻塞模型或者协程的语言框架，但是这就是另一个技术选型的复杂问题了

[tcsky]

@neoblackcap 一般需要考虑点比较多, 例如团队技术栈, 业务场景, 历史系统； 其实一个项目拆解后, 各层侧重点不太一样. 一般像前端网关或 API 部分期望能支持更多并发, 业务处理部分则倾向于第三方组件完善, 开发调试简单, 其他人易于理解等. 另外一般真出现加机器都解决不了时, 基本公司已经比较成规模 l, 内部各系统方案就更多种多样了.

[sampeng]

测一下基准，不要在原油项目上测。一般问题都很好解决

[xiaoshenke]

@jokerlee 服了，你哪里看到的？ dubbo 就是用 nio 写的…现在谁写框架不用非阻塞 io ……

[jokerlee]

楼主这个问题从经验上看就是 tomcat 线程池跑满了，请求排队了。

这个问题可以这么确定，在系统高延时看一下系统的 cpu 磁盘 网络 内存有没有任意一项被打满了，没有的话就不要去优化代码了，调调各种配置先让某个资源打满再说

[sagaxu]

@neoblackcap 因为异步代码比同步的难写的多，写框架和底层还行，业务逻辑错综复杂，比如同步循环里阻塞调用其它服务，根据其它服务的返回值做 break 或者 continue，异步的方式也能无脑写吗？

小项目堆机器更划算，3 个 15k 开发能搞定的事情，换成异步可能要 4 个 30k 的开发，一年多 100 万成本，加 10 台高配服务器都够了。嫌弃 cpu 切换开销大？来 20 个核，只做切换，别的啥也不干。

1000 线程时，切换开销比前置 nginx 的开销还小，把一个只占不到 1/10 的东西优化到 0，提升也不明显。

[jokerlee]

@xiaoshenke 你试试用 rxjava 或者 java8 自带的 CompletableFutrue 写个复杂业务试试，比同步模型写代码速度慢不知道几倍，java 只要不加协程，业务层就不可能大规模应用非阻塞模型

[xiaoshenke]

@jokerlee 你说的是 rxjava 啊… rxjava 只是响应式风格 api 吧不是非阻塞模型

[xiaoshenke]

@jokerlee 不过这玩意不是很熟 不做评价