标签:基准测试 连接 水平 硬件 use 级别 数据库 句柄 运行时间
性能测试时通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,查看系统各项性能指标的变化情况。
是通过确定一个系统的瓶颈或者不能接受的性能点,来获取系统能提供的最大服务级别的测试。
增加系统资源占用、系统长时间的大并发运行或正常流量的系统访问等,验证系统长期稳定工作的能力。
一般跑7*24H
为了发现内存泄漏、句柄泄漏、连接数泄漏、算法问题。
性能测试的误区:并发量越大系统压力越大
并发量与每秒交易量的联系:
并发量用于考察系统的用户支撑能力
每秒交易量才是衡量大多数系统的真实压力的正确指标
随着并发量的增加TPS并不是线性增长的
TPS 和Trans Response time(事务的平均响应时间)是非常重要的两个指标。
测试目的
测试范围(交易列表、路径图等)
性能指标(要可测量,量化指标最好给出具体数值,无法定量的给出说明)
一般接口的性能响应时间是50ms以下可以接受,50-100ms比较缓慢。
数据量(给出具体数值和参考数据,无法定量的给出说明)
测试环境(分为网络、硬件、软件)
测试工具和监控工具及其相关环境
测试策略
时间周期
吞吐量TPS
每个事务的平均响应时间
确定数据库的数据量
系统的稳定运行时间要求
是否需要考虑系统的支持水平扩展(增加硬件是否能增加系统的处理能力)
考虑系统的最大容量
用户经常使用的功能
产生IO操作比较多的功能
系统的核心功能
系统产生密集计算的功能
基准测试:获得各个典型交易在无压力条件下性能表现
单交易负载测试:获得呵呵典型交易在负载条件下的性能表现
混合场景序列负载测试:按照场景序列一次获得各个场景负载条件下的性能表现
稳定性测试:通过长时间、较大压力的负载运行,获得被测系统的稳定性表现
目的是检查业务本身是否存在功能缺陷,同时为将来的混合场景性能测试分析提供参考数据
测试方法:
编写测试客户端向应用服务器发送业务请求并接收返回结果的脚本
在系统无压力的情况下重复100次,每次迭代时间等待1s
取业务的平均响应时间作为衡量指标
目的是考察系统交易编码是否存在性能隐患
测试方法:
编写测试客户端向应用服务器发送业务请求并接收返回结果的脚本
使用20%系统标准并发量进行测试,或者压倒出错为止。
测试方法:
按照业务模型比例设置测试场景
逐步增加并发量
记录每次测试环境参数:包括数据库配置参数、应用系统配置参数
收集系统性能变化曲线
标签:基准测试 连接 水平 硬件 use 级别 数据库 句柄 运行时间
原文地址:https://www.cnblogs.com/xiaojingliu/p/13289530.html