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

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

[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 并发每日不小了，只能说规模不一样。