测试的目标
1、找到硬件设备的性能拐点,为设备规划合理的工作负载;(硬件的利用率和负荷处于较高水平,可能宕机或拖慢服务的响应速度)
2、找到系统的性能瓶颈,优化服务的实现方式;(硬件的利用率和负荷处在正常水平,但是服务响应的延迟时间比较长)
3、回答当前的系统能承载多少访问量
性能拐点
系统的性能主要由 支持多少并发访问 和 访问延迟时间 体现。自己的测试工作有 确定当前硬件条件下某个大数据组件在规定的延迟时间限制下所能支持的最大并发访问量 这个中心,也就是回答 当前的配置能够支持多大的场景 和 某个场景需要什么样的配置 这两个问题。
根据下图的淘宝性能测试曲线,将单个服务器的TPS设置为 $ A_y $ ,可以兼顾利用率和运维的可靠性。
性能瓶颈
场景:针对场景进行优化,减小响应时间,提高吞吐量
1、登录:限制响应时间
2、查询:限制响应时间
容量
单节点性能 * 节点数 / 加速比(节点与加速比对应表) >= 容量
系统支持全所6W职工同时访问系统
PV计算带宽
假设网站的平均日PV:10w 的访问量,页面平均大小0.4 M
网站带宽 = 10w / (24 *60 * 60)* 0.4M * 8 =3.7 Mbps
PV与并发
假设网站的日平均PV:10w 的访问量,页面平均大小0.4 M,50个派生连接数
并发连接数 = (100000PV / 86400秒 * 50个派生连接数 * 1秒内响应 * 5倍峰值) / 1台Web服务器 = 289 并发连接数
PV计算QPS
系统1天内的总访问量是10w pv,该落地页的衍生连接数为50,那么系统的平均QPS
平均QPS = 100000 * 50 / ( 8 * 60 * 60 ) = 171
峰值QPS大概是均值QPS的3-5倍
峰值QPS = 171 * 5 = 855
需要测试得到的数据:
网络带宽、单机极限并发连接数、单机极限QPS
附指标:
网站带宽= PV / 统计时间(换算到S)*平均页面大小(单位KB)* 8
并发连接数 = PV / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / web服务器数量
QPS = req/sec = 请求数/秒 = 并发量/平均响应时间 = 总请求数 / ( 进程总数 * 请求时间 ) , 服务器数量 = 峰值时间每秒QPS / 单台机器的QPS
参考:
https://www.cnblogs.com/ratels/p/10995587.html
https://www.cnblogs.com/LBSer/p/4605345.html