记一次性能测试经验总结

在最近的一次压测中,由于分别使用了Jmeter和阿里云的PTS,所以发现了些平时压测时的错误理解

一直依赖对并发数而忽略是请求次数所以得到了不同的结果

此图是我用jmeter压测的结果

 

可以看出我的压测机的各项资源均处在合理的范围内,但是从服务端的监控中可以看出,活跃连接数刚好是500多点,但是最大并发连接数却直接飙升到了1400+.这不得不让我感到怀疑,我此次压测的并发到底是多少?

在重新梳理过并发数和请求连接数的感念之后得到了一下的结果

并发数:客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器链接的总TCP数量，就是并发连接数。

请求连接数:可以叫QPS也可以叫RPS。单位是每秒多少请求。Query=查询，也相当于请求。请求数指的是客户端在建立完连接后，向http服务发出GET/POST/HEAD数据包，服务器返回了请求结果后有两种情况：

• http数据包头包含Close字样，关闭本次TCP连接；
• http数据包头包含Keep-Alive字样，本次连接不关闭，可继续通过该连接继续向http服务发送请求，用于减少TCP并发连接数。

 所以通俗的来说,常说的并发只是,客户端与服务端建立了TCP连接,而请求连接数+并发数才是,一次完整的数据来回

为了更好的验证并发数和请求次数的问题做了一下几种尝试

        由于是登陆接口,分配了100个不同的账号,为了避免有的请求是读取了缓存,而有的请求是读取磁盘所以在跑过一轮之后,在分别跑三次

1:1的并发,跑5秒

 2:1的并发,跑5秒

        总请求次数avg:70,每秒请求连接次数:12/s

3:10的并发跑5秒

        总请求次数avg:600,每秒请求连接次数,120/s

        总请求次数刚好是10倍的提升

4:1的并发,跑1秒

         总请求次数avg:13,每秒请求连接次数:13

5:10的并发跑1秒

         总请求次数avg:101,每秒请求连接次数:101/s

jmeter设置的并发量与真实服务器感受到的压力值是不一致的,如果想要计算出,当前服务器的并发压力,还是需要通过基准测试之后,在进行计算!

        假设500的并发跑60秒,那么计算服务器每秒所承受的压力值(标准按照我刚刚上述所说的来计算,完全不考虑服务器的响应延迟,网络延迟等问题)

        总请求连接次数=500(c)*10(平均每秒的请求次数)*120 <= 600000

        平均每秒请求连接次数 = 500*10 <= 5000

通过上述的例子,可以看出想要真正的控制好对服务器的压力值,要是要进行以下几个步骤

1:基准测试,只有进行了基准测试,才能推算出实际的每秒并发连接数的值

2:对所有的数据进行通跑,使其避免由缓存所带来的数值偏差

3:不要过分依赖,你所设定的并发数,因为它并不是正在的并发请求连接数