性能压测

性能压测
QPS和TPS
QPS
Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS
TransactionsPerSecond是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
TPS事物
Tps包括三个过程,分别是:
用户请求服务器
服务器自己的内部处理
服务器返回给用户
QPS和TPS区别
一次TPS表示一个事物的完整过程,这个过程中可能包含多个QPS。例如:访问一次页面是一次TPS,访问页面的时候页面有多个请求,每个请求算一次QPS。
系统吞吐量
单位时间内系统处理请求的数量,体现系统的处理能力。
吞吐量 = (1000/响应时间ms)x 并发数
系统吞吐量几个重要參数:QPS(TPS)、并发数、响应时间
QPS(TPS):每秒钟request/事务 数量
并发数: 系统同一时候处理的request/事务数
响应时间: 一般取平均响应时间
压力测试曲线图

伴随着并发数的增加系统响应时长和系统吞吐量表现出不一样的变化趋势。
绿线代表CPU使用情况
红线表示系统吞吐量
紫线表示系统响应时间
系统响应时长变化
随着并发数的增加,系统响应时间的变化可以分为三个阶段。
第一阶段
低负载阶段,系统资源利用率很低,系统响应时间随着并发数增加变化不明显,也可以理解为并发数增加并未对系统响应时长造成太大影响。
第二阶段
高负载阶段,系统利用率较高,系统响应时长随着并发数增加出现大幅增长,在此阶段并发数对系统响应时长的影响很大,其主要原因是因为系统资源满载了,请求数量大于CPU的核心数,导致进程或者线程不断切换,响应耗时增大。
第二阶段
过载阶段,系统利用率接近最大,系统过载。由于请求数量远大于CPU核心数量,系统为了处理如此大量的请求,进程(线程)频繁切换,导致系统响应时长成指数增长
系统吞吐量变化
同系统响应时长,系统吞吐量变化也可以分为三个阶段
第一阶段
低负载阶段,系统利用率低,CPU存在空闲的情况,此时随着并发数的增加系统吞吐量正比例增加。
第二阶段
高负载阶段,系统利用率达到瓶颈,CPU核心满负荷工作,此时出现进程或者线程不断切换的情况,导致随着并发数的增加系统吞吐量缓慢增长甚至出现小幅度下降的情况
第二阶段
过载阶段,系统利用率过高,过多的请求导致CPU疲于应付,进程(线程)频繁切换,真正用于处理请求的时间变少,能够处理的请求数反而变少,系统的吞吐量出现明显的下降。
实现简单web压测工具
用你熟悉的编程语言写一个 web 性能压测工具,输入参数:URL,请求总次数,并发数。输出参数:平均响应时间,95% 响应时间。用这个测试工具以 10 并发、100 次请求压测 www.baidu.com。
首先实现一个任务类 Tasker
然后准备一个压测结果类StressResult
最后实现压测工具类StressTasker
执行压测任务
执行结果

然后再尝试压测其它类型的网站
淘宝

京东

infoQ

CSDN

综合可得,网站性能由高到底:搜索引擎网站 > 购物网站 > 博客类网站
版权声明: 本文为 InfoQ 作者【拈香(曾德政)】的原创文章。
原文链接:【http://xie.infoq.cn/article/865b929dc52202fd8ad3d3698】。文章转载请联系作者。
评论