这是一个创建于 2170 天前的主题，其中的信息可能已经有所发展或是发生改变。
上周项目在线上使用的时候发生了个问题,一两秒内 300 个并发时服务器就死掉了,tomcat 没有崩溃但是就是请求没有响应不知道为什么?昨天用 jmeter 尝试复现,由于之前没有 jmeter 做过压力测试用,不知道是不是配置的不对,500 个并发服务都没有事情,最后和同事对接了下才发现压错了接口,崩溃的接口对数据库读写比较多所以死掉了,后来去压那个接口发现果然抗住不,看了下数据库连接池发现竟然是 c3p0,后来果断改成了 druid 然后就没事了.
关于这件事让我产生了一个疑问,做压力测试时如何根据测试的情况来推断出服务器在线上能抗住多少的并发呢?
 |
1
yestodayHadRain OP 补充一下,项目是传统项目平时用户量比较少只有特殊的情况下才会有几百年的并发,另外线上使用的时候是直接部署在 win 上面的,虽然我也想部署在 linux 上但是公司是这样要求的,最后的最后 代码不是我写的......
|
 |
3
hflyf123 2018-12-11 09:23:33 +08:00
压力测试目的是在软件投入使用以前或软件负载达到极限以前，通过执行可重复的负载测试，了解系统可靠性、性能瓶颈等，以提高软件系统的可靠性、稳定性，减少系统的宕机时间和因此带来的损失(压到崩为止）
|
 |
4
SoulSleep 2018-12-11 09:27:26 +08:00
看了下数据库连接池发现竟然是 c3p0,后来果断改成了 druid 然后就没事了.
替 c3p0 伸冤，这锅我不背，是你不会用 然后 druid 也有 bug 1.0.10 版本之前，不告诉你，等你踩坑。。。昂~ |
|
5
yestodayHadRain OP @SoulSleep 那麻烦大佬告诉我下 c3p0 的正确使用姿势 还有 druid 的 bug
|
|
6
yestodayHadRain OP @SoulSleep 这个坑踩的成本太高了,万一以后线上在出问题了,就是我的锅了,会影响好多人的
|
|
7
SoulSleep 2018-12-11 09:39:43 +08:00
@yestodayHadRain #6 你用最新版本就行了，已经修复了，我们就被坑过，即使我们的数据库做了高可用，但是这个 bug 会导致 druid 的连接异常
|
 |
8
lingll 2018-12-11 09:41:53 +08:00
开发兼做测试? 没有专门的测试人员吗?
|
 |
9
luosuosile 2018-12-11 09:49:37 +08:00
好文收藏
|
 |
10
loveCoding 2018-12-11 09:51:51 +08:00
那你从 c3p0 换成 druid 连接池参数变化了什么? 还是没有找到导致崩溃的原因啊
|
 |
11
tt67wq 2018-12-11 10:21:33 +08:00
站在电脑上测试，给它一点压力
|
|
12
yestodayHadRain OP @lingll 公司没有测试，因为我之前做测试的老大就让我搞了，可是我之前没搞过压力测试
|
|
13
yestodayHadRain OP @loveCoding 老大说那天用的时候 tomcat 并没有崩溃，只是卡住了所有请求都是 loading，所以我认为是之前的数据库连接池性能不够好前面的资源还没释放后面排队的就来了，就这样一直堆积最后阻塞了。当然这只是我的猜测，我是个小白
|
|
14
yestodayHadRain OP @SoulSleep 我今天又去压昨天的那个接口，发现有系统异常大致意思是线程池达到了最大，但是把 jmeter 关掉就能正常访问了(用 c3p0 的时候关掉了 jmeter 访问也是一直 loading)，能不能分享下你们的 druid 参数设置呢？初始化，最多，最少 只要这三个就成
|
 |
15
saltxy 2018-12-11 14:31:30 +08:00
直接压线上的接口吗？不应该是压测试环境的接口，然后估算线上可承受的压力吗。
不知道大厂是怎么做的 |
|
16
yestodayHadRain OP @saltxy 是在测试环境压的接口,但是用 jmeter 模拟出来的线程和线上真实用户操作还是有区别的,另外我在线下用 jmeter 做压力测试,单机版 tomcat 部署在 win 上面,2000 个线程并发 服务都没事,这样讲就能说 线上单机版 tomcat 能抗住 2000 的并发吗?这样肯定是不合理的
|
 |
17
sagaxu 2018-12-11 17:24:39 +08:00 via Android
推荐 hikariCP，阿里的开源项目，我是不敢用的。还有那个 fastjson，并不 fast，坑还很多，阿里自己一些项目也不用它。
|
|
18
yestodayHadRain OP @sagaxu 大家好像有些跑题了，title 是关于大家平时是如何做压力测试的，说着说着变成连接池讨论了
|
 |
19
linil 2018-12-11 22:00:13 +08:00 via Android
我们以前是布了一套和生产差不多的环境。
另外分布式的情况是测试一台的能力，然后后面不够了就加服务器布置多一个节点，当然前提是确保入口抗得住（如用 Nginx 的话就先测 Nginx 的能力） |
|
20
yestodayHadRain OP @linil 你们做压测的时候是用什么来做的呢?
|
|
21
linil 2018-12-12 19:17:36 +08:00 via Android
@yestodayHadRain 你是指工具吗？公司没要求，我是用 JMeter 的。
|
|
22
yestodayHadRain OP @linil 我也用的是 jmeter，但是我开 2000 个线程去压接口，服务没挂，就能说明服务能抗住 2000 的并发吗？而且我用 druid 的监控平台看，虽然是 2000 个线程去压但是接口的最大并发才只有 200 这是为什么呢？
|
|
23
linil 2018-12-12 19:52:56 +08:00 via Android  1
@yestodayHadRain 服务没挂代表短时间内抗住了 2000 线程（可认为是 2000 用户），但不代表 2000 并发，而且你看并发看 JMeter 的 TPS 那个值而不是设置的线程数。
|
|
24
linil 2018-12-13 12:44:30 +08:00 via Android 1
有点忙，上面匆匆回复了。
比如你是开了 200 个窗口处理业务，每个窗口一秒可以处理一件业务，也就是最大业务处理速度就是 200TPS。 现在来了 2000 个客户，这个时候你总的处理速度还是 200TPS 的，其他客户就必须排队，结果导致的是平均每个用户的等待时间变长了（就是响应时间）。 |
|
25
yestodayHadRain OP @linil
1.我从 jmeter 的聚合报告看并没有看到 TPS 参数，请问这个是算出来的吗？ 2.第二个问题，既然 jmeter 的并发线程数不能够说明系统的最大并发，那么请问如何根据测试数据估算出线上能抗住的最大并发呢？ |
Select Language