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

[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 的都是靠缓存顶住的吗？不上缓存的话，我现在服务器的性能指标到底是否正常？

[night98]

4c8g 应该性能不会这么差，排查下那几个点耗时长再优化

[abcbuzhiming]

@night98 没有长耗时，我检查过数据库，就是最简单的 select 单条记录，从浏览器前端到应用服务器，应用服务器从数据库读取再返回给前端，就要 20-30ms。所以我现在很想找个参照物，这个过程又没有能压到个位数毫秒级的让我见识一下

[sujin190]

没怎么用过 java，但是 python 的 tornado 做的 curd 延时平均差不多 3ms，内网延时普遍应该 1ms 吧，简单 sql 2 到 3ms 可以返回了吧，框架不可能慢吧，spring 应该有性能分析工具吧，可以看看是数据库慢还是框架慢

不过认真说，实际项目 500 感觉不低了吧，还是加机器缓存靠谱

[sylxjtu]

@abcbuzhiming 用 show profile 应该能知道在服务端的延时吧，可以知道到底网络问题还是 sql 的问题

[ittianyu]

500 就高并发？
你们公司规模得多小，手动滑稽。
让我这个曾经做安卓应届生来给你点小建议

数据复杂的可以考虑 join 拆分成多个单表查询，然后在 java 里面关联起来。
数据长时间不变的上缓存。
几万并发的集群+缓存基本就可以解决。

整个项目几万到十几万的并发，就拆分项目，也就是 SOA 或 微服务。主要是分摊压力，解决数据库和入口大流量瓶颈问题。

what ？在往上怎么办？这么大的用户群，会让我这种应届生来做架构？这种问题，有请下面的大佬来回答。

[hopingtop]

根据你描述的点可以测试两个点
1. 数据库机器到应用机器的网络，单纯的数据读取
2. 只测试序列化的时间

如果上述都 ok，在考虑线程是否优化，sql 等

[ashes1122]

@ittianyu 你连题主的描述和需求都没看完吧?

[luban]

500 并发我觉得不低了，工作七八年还没接触过超过 500 并发的系统

[lxrmido]

@ittianyu 你没看题，你这只是解决了你设想的高并发，然而楼主遇上的显然不是

建议楼主换高性能的 RDS

[qiuqiuer]

有个过时的东西叫，内存变硬盘

[liprais]

现在应届生阅读能力这么差了 ？
老实讲不上缓存 500 并发不低了，不过还是先做 profile 看看时间都花哪了
单表查询 mysql 应该可以做到 5ms 以内没问题

[ooTwToo]

想要马儿跑得快，又不给马儿吃草？

[dengtongcai]

20-30ms 整个请求响应过程，确实就算一个普通 select 最低也要这个时间

[Ico945]

首先赞同楼上的，用工具看看是哪部分慢。数据库的话 查看你的 crud 语句是不是可以继续优化，表的结构是不是合理

[ittianyu]

@ashes1122 不好意思，确实没往下看了，单机一个 tomcat 200-500 并发是正常的，多加机器，别折腾了。

[metrxqin]

> 这样的两台(一组)服务器，能抗住多少并发呢，500 不到

请把测试相关信息也发出来，比较关键的信息 CPU 负载情况、Tomcat 线程池使用情况、应用数据库连接使用情况，另外在高并发时使用 jstack 打印出最繁忙的线程堆栈。

另外还有主机的带宽使用情况和 ss -s 输出内容。

[metrxqin]

另外还有测试请求内容大小和响应大小。

[xiaoshenke]

性能问题一般就是带宽，数据库，线程数。你这个数据库有点慢了。

[lhx2008]

不上缓存的话，用 Netty 上面的异步框架进一步压缩一下多余的开销，然后暴力线程池来等 Mysql，至少能抗两三千吧，具体看业务了。

[lhx2008]

https://github.com/xenv/gushici#%E5%8D%95%E6%9C%BA%E5%8E%8B%E6%B5%8B

vert.x + netty + redis 可以做到超高并发的 10ms 内稳定返回，如果旧项目不好转的话 Spring Webflux + netty 也是不错的选择。

[me15000]

看看哪个进程占用 cpu 多啊？
是数据库，还是站点啊？

数据库有 sql 性能监控工具分析下 sql 占用
站点问题就看看是哪些页面语句引起的

性能优化的关键是如何找出性能瓶颈

[teli]

吓死我了
这也就真正的高并发

云数据库+分布式+缓存

[abcbuzhiming]

@sujin190 查了一下，发现应用服务器访问数据库服务器的速度并不慢，确实如你说，个位数的 ms 就结束了查询，但是，如果加上前端网络请求，到 json 数据返回，就慢了，无论如何也压不进 10ms，基本都在 20ms 以上

[SlipStupig]

我做过 PVP 游戏服务器，8CORE 8GB 用 mysql 做数据库上线峰值 1500 人，还能扛得住，你目前性能上面感觉是完全够的，如果条件允许可以做这么几件事：

1. 带宽问题 ：检查阿里云带宽使用情况
1.1 入口带宽被爬虫或者业务占满了，看一下阿里云带宽情况是不是把带宽撑死了导致业务无法正常工作，解决方案：加大带宽，上 CDN 的话能缓解一下
1.2 线路问题，使用一些云测速工具看一下全国情况，看情况如何，如果正常则可以排除

2. 检查服务器基本状态问题
看一下连接表：如果出现大量“ TIME_WAIT ”，说明被占用了大量链接没正常释放，这个得具体分析没有太好的解决方案

3. 应用配置不当
3.1 本身程序逻辑写的有问题，导致有性能异常缓慢，这个只能做 Profileing，特别是要保证数据库有没正常开关连接，并且没有用数据库做一些计算和 offset 和排序操作。
3.2 tomcat 配置不当，主要表现少量请求下性能正常，并发量大完全打不开，解决方案：优化 Tomcat 配置

4. 数据库问题
4.1 数据数据结构有问题并写了很多垃圾 sql 语句把数据库活活拖死，这个需要开启 slow log 进行分析，并看一下当前查询语句情况，如果从面板上看 qps 很小却速度很慢，基本上可以断定是数据库的问题
4.2 数据库配置不当，mysql 默认配置主要是为了让业务起来而不是高并发，这个主要表现是数据库占用很低但是性能很差，需要做 benchmark

希望能帮上你

[abcbuzhiming]

@lxrmido 你的意思是 MySQL 在这种情况下不行？ 4 核 8G 就这点性能？

[sagaxu]

JVM 的线程池一般也就核心的 1.5-2 倍？

对此表示怀疑，只要 cpu 占用率低，内存足够的时候，线程池是核心的 10 倍甚至 100 倍也行。

[abcbuzhiming]

@metrxqin CPU 负载，无论是应用服务器还是数据库服务器，到应用服务器影响明显变慢变卡顿时，CPU 资源的一半都还没吃掉，数据库 CPU 停留在 38-45%之间，应用服务器最高也就 60%的 CPU，内存，带宽，远远没吃满

[sujin190]

@ittianyu 是不是对并发有什么误解，500 并发每日已经数百万 pv 了吧。不小了，动辄数万数十万的国内也没几个吧，而且你确定不是整个公司做了大量基础服务支撑而是你自己搞的

[abcbuzhiming]

@SlipStupig 谢了，我现在遇到的情况就是并发量大了就打不开，但是此时服务器的硬件资源 CPU，内存，带宽都没有到吃满的程度

[abcbuzhiming]

@sagaxu 我建议你读一些关于 Java 多线程方面的书，java 的线程都是内核级的线程，没有实现自己的用户线程，这就导致 java 的线程切换是 1 个代价很高的事情。因此才有推荐 java 的线程数大约是逻辑内核的 1.5-2 倍的这个值，因为更多没有，至于你说的 10 倍，100 倍，我保证，你搞这么多线程，不是根本用不上，就是消耗在线程切换上的时间比计算时间还多，毫无意义

[sorra]

性能测试、性能监控、性能分析，拿到总时间和瓶颈时间的平均值、中位数、方差
你就什么都知道了

附赠一些细节：
- 数据库简单查询可以<1ms，这个 20-30ms 值得分析一下（未必是花在数据库上）。但缓存也早晚要上的
- 你的 Tomcat 线程池大小、数据库连接池大小，弄清楚
- 注意一下日志量，可能影响性能哦

[sujin190]

@abcbuzhiming 那就是框架慢了，是不是加了太多插件，单纯 http 编码解码不可能这么慢的，现在框架大多是插件式的，tornado 延时这么低很大因素就是纯框架，啥多余的都没有，比如另外 php 的 laravel 比较复杂，普通 curd 就已经 100 延时了

[ittianyu]

@sujin190 照你这么说，tomcat*2 就完全够支撑大部分公司的需求了？
照你这并发的理解，随便搞个抢购活动分分钟就宕机。

[wdlth]

@abcbuzhiming 你是怎么把对象转换成 JSON 的，直接用 Spring 的 Message Converter 么？

[huhu3312]

我感觉楼主的机器是正常的，你说 json 到页面响应只有 20-30ms，那接口速度很快了啊。建议看看带宽之类的数值，在阿里云 rds 控制台上看看，看看你业务高峰的时候带宽到多少了

[cpdyj0]

研究下慢在哪里，如果是 io 可以考虑切换到 vert.x 这种异步框架，，，如果是慢在计算就只能加机器了呗。

[janxin]

单机 500 就是高并发了？我们对 Java 的理解不太一样吧？最起码的系统优化应该做了吧？

[sagaxu]

@abcbuzhiming 你知道四核 cpu 上，10000 个线程的时候，linux 内核做一次线程调度，上下文切换开销多大吗？微秒级别，比较古老的 cpu 上，也不过 10 微秒级别。

而 10000 个线程，通常需要配备 10G 内存。所以我们一般不会开 10000 个这么多，但是几百个上千个是很轻松的，1000 个线程的时候，上下文切换占用 cpu 的开销还不到 10%，完全可以承受。

tomcat 默认线程池大小就是 200，这个数值一般是偏保守的，难道说大部分人都是 100 核以上的机器？



我们之前一个 IO 密集型项目里，几台 backend 都是开 1000 线程或 2000 线程，日 pv 几亿。

[abcbuzhiming]

@wdlth 用的 jackson 来进行 json 序列化

[ittianyu]

@sujin190 忘了说了，抢购只是打个比方（一般 nosql mq 来解决），但每天访问量又不是平均的，高峰期过 1000 并发很常见。你跟我说 500 并发每日不小了，只能说规模不一样。

[showecho]

技术我不懂，但是 500 并发说很低的人，你们真的实操过吗？
并发 500，一天流量得多少，有多少企业能到？

[wuhhhh]

tomcat 本身并发访问就 600 是最佳，越往后越容易丢失，大概 1000 左右就会崩溃，所以如果想要做高并发，就必须考虑动态静态资源的分离，用 nginx 做反代或者静态资源存储，动态就靠缓存或者升级服务器来实现，再往上的解决就不是程序员的问题，是架构师本身能力了

[SlipStupig]

@abcbuzhiming 硬件没问题，多分析代码问题吧

[seancheer]

首先排查网络，磁盘，cpu 问题
然后观察 java gc
最后代码涉及到 io 的地方进行打点，观察方法执行的时延
一步步缩小怀疑段

[micean]

不到 10 个线程，做的 mysql 的 crud 的场景，那能不慢吗？
把线程池加到 200 就正常了
如果你想要异步化的 crud，抛弃 jdbc，转 scala，有人重写了 mysql 的客户端

[gsggwbz]

用消息队列进行流量削峰，java 后台服务层用线程池实现并行异步执行，数据层上缓存，并发量集中的页面考虑做成静态页面，减轻服务端压力，负载均衡集群做下。

[micean]

再说一下，一般说的按核心数计算线程数是用来给非阻塞线程的，阻塞线程要按实际情况调试

[metrxqin]

很奇怪，你先试试导出堆栈。

[ccnccy]

前几天有 2 台服务器负载超高，30 左右，看了下很多 time wait, 两台都是 centos 7.1, 看了下其他的 6.9 的都没问题，后面把这两天装回 centos6.9，问题解决。

[opengps]

首先问下，你的 mysql 在什么硬盘上，云服务器的硬盘性能都很低。
你有必要换 ssd 或者直接使用阿里云提供的 RDS for mysql.

看到很多人觉得 500 不是高并发，我笑了，实际上很多人的项目，使用单台云服务器，根本支撑不到 500 并发，做一次公网环境的压测，会深深地意识到自己技术水平的不足，然后才会理解为什么云架构这么受欢迎（简单说：流量来了加机器即可解决）。

[weizhen199]

500 的并发事务的话，已经非常大了

[CoderGeek]

1.如果有 slow api 分析看一下是否涉及到 cud 持久化操作调用有问题
2.看一下 sql 的 slow。 优化一下你的 sql
3.阿里云 ecs 的实例类型 是否购买成共享型 cpu 了 被别的人强了资源也会这样 cpu 直接爆了 （仔细观察一下服务器资源）
后面才是代码 gc 和 数据库配置
还有不是核心数据做 log 异步处理一下

[D3EP]

楼上说的对。你说的线程数是 CPU 核心数的 1.5 或 2 倍 指的是计算密集型的任务。Tomcat 默认 200 个线程。不要看书看得太教条了。多开点线程没啥问题。

[CoderGeek]

我之前买的几台服务器实例 全部是共享型的 有一次数据库的那台服务器 cpu 直接爆了 前几周 ali 才告诉我 我都要坑死了 挪了二十几台服务器 没气死我了...

[SoCrazyStone]

收藏了,看大佬 battle

[CoderGeek]

我现在用的是 rds mysql 和自建的核心数据库 仔细看下服务器吧。。。

[zorui]

@ittianyu 应届生无疑。。。

[lxrmido]

@abcbuzhiming
4 核 8G 不是问题，瓶颈压根就不在 CPU 和内存上，对于 500 个写数据库的并发操作而言，瓶颈在磁盘 IO 上，只是不知道是底层存储云的网络 IO 还是 SSD 的磁盘 IO，假如你们没有对数据库配置比较了解的人的话，换 RDS、加机器的性价比可能会比较高。

[Infernalzero]

你怕是没改配置还用的是 BIO 吧？

[hand515]

日志打太多了吗

[CoderGeek]

你这描述 并发 500 不应该不用缓存的 ... 我这高峰 API qps500+ 都是 3 台你这配置的服务器+slb
一台也顶得住但是你作为线上业务 不应该单台的 单点故障。

[ittianyu]

@zorui 那还真是抱歉了， 不是做 java 的我不该来这看了个标题瞄到一个 500 就开始评论。一堆人讽刺，告辞！！

最后说 认为 500 并发很低的人没实操过的，我不想说话(随便开十几台机器做压测会达不到 500 ？)，500 那么高的并发，那是不是可以这么理解，99.99%的公司有两三台服务器就够用了。
我又没说单机 500 并发很低，单机能到 300 就不错了，我说的是整个项目 500 并发很低。
算了， 告辞！！

[Actrace]

阿里云的 vps 你还是要考虑一下超售的问题的。

[vnex]

@sagaxu #38
请教下

你知道四核 cpu 上，10000 个线程的时候，linux 内核做一次线程调度，上下文切换开销多大吗？微秒级别，比较古老的 cpu 上，也不过 10 微秒级别。

而 10000 个线程，通常需要配备 10G 内存。所以我们一般不会开 10000 个这么多，但是几百个上千个是很轻松的，1000 个线程的时候，上下文切换占用 cpu 的开销还不到 10%，完全可以承受。

这个的计算是:

1000 个线程: 10us * 1000 == 10ms == 1% cpu

10000 个线程: 10us * 10000 == 100ms == 10% CPU

这样吗?

[ebony0319]

上个星期遇到了一个项目，感觉跟楼主差不多，最后临时把阿里云带宽加到 100M 就好了，就是这么神奇。你可以试下是不是带宽的瓶颈。

[neoblackcap]

@ittianyu 之前就有人做过测试，inner join 跟子查询的性能基本没有区别，在单机 mysql 的情况下更是如此。

[jokerlee]

加内存缓存 提高 tomcat 线程数到 500
tomcat 一般都是 io 密集操作 线程要开大，不然线程都是 block cpu 跑不满

[rogerchen]

这么简单的问题，群魔乱舞。
profile 一下搞清楚为什么 mysql 毫秒级返回，前端请求加 json 解析需要 20ms+。
如果是网络延迟，多开十倍的线程。
如果是 json encode decode 卡计算，换 rapidjson 这种高效 json 库。
如果 mysql SSD 吞吐打满了，换 RDS。

[jdgui]

楼上说 500 并发很小的。。
多半是纸上程序员吧。真的实际坐过这些的应该不会觉得这个小。

[ittianyu]

@neoblackcap 我说的是集群的情况下，减少对数据库的压力，耗时的事放在 java 上做，容易扩展。
我答的时候没细看楼主的问题。

[neoblackcap]

@sagaxu 为什么要开那么多线程呢？按照 nginx 的思路，要解决大并发以及 IO 密集型业务也不需要那么多的线程吧。过多线程之后徒增上下文切换的成本。毕竟 IO 又不占 CPU 时间片，用 IO 复用机制加非堵塞 IO 解决不好么？

[jokerlee]

@neoblackcap 你要理解同步模型和异步模型的区别

[rogerchen]

@neoblackcap 无脑加线程本来就是解决 IO 的合理方法之一，特别是规模小的时候

[tcsky]

你试试调大线程池,

你说的线程数微多与核心数 一般针对的是 cpu 密集型的应用, 如用来一些异步框架
io 阻塞的情况下 需要调大线程数, 看你 API 相应时间在小几十 ms, 你调整线程数到 100 试试. cpu 跑满后 qps 会趋于稳定

500 并发其实不小了，普通应用一天 10 小时算, 都快 2000 万 pv 了, 另外只要不是连续的突发流量, 应用都撑得住的, 一般应用用的 tcpserver 自带队列,或者会抛弃超出负载的连接. 对应现象是响应时间变长, 或部分请求会失败

[palmers]

我也觉得应该把各个业务节点的耗时整理出来然后再讨论优化 这样才会有着力点 才会知道是网络需要优化还是业务需要优化 不要小看每一个点的优化 累计是很客观的

[wjqxhy]

个人觉得可能测试的模型是建连接，发请求，断连接这个完整的过程
建连接是比较耗时的，如果用 ab 测试工具的话，应该是能看到这部分的耗时，看是不是较高

如果是的话，看看服务器端是否支持了 keep-alive，如果支持，使用 ab 测试的话可以加-k 进行，或者用 wrk 工具
另外也可以调整内核参数优化性能

[neoblackcap]

@jokerlee 那两个模型理解啊，就是理解了我才觉得多线程没法很好地解决 IO 密集业务。linux 下线程上下文切换虽然成本低，但是多了也不少啊。
而且基本上所有 linux 的 IO 都能设置成非堵塞 IO，加上 IO 复用机制，这个不是将 CPU 更好地利用么？我是没法想象出一个不能用 IO 复用机制+非堵塞 I+线程池替代单纯多线程处理的场景。因此我才觉得这个场景比较奇怪，想问问当成为什么这样考量。

[neoblackcap]

@rogerchen 你这样一说我倒是可以理解，不过这个始终不是长久之计，毕竟线程多了，上下文切换成本高，得不偿失。

[tcsky]

@neoblackcap 两种模型各有优缺点,
异步模型开发成本会更高一点, 如果业务很轻, 需要支撑大量的 tcp 连接, 走异步模型比较合适.
其他情况下开线程就行，简单快速, 性能损耗也不明显.

[jokerlee]

@neoblackcap 一般应用根本用不着去抠线程上下文切换的性能消耗 而且业务层不是都能写成无阻塞模型的

[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 不过这玩意不是很熟 不做评价