1.1 性能测试需求内容
1.2 预期性能指标

1.2.1数据量
测试环境的数据量,应该跟线上环境保持一致,至少要在一个数量级。
1.2.2高峰业务PV量
     1) 二八法
若80%的访问量集中在20%的时间里,可用此分析方法,其图形就是一个正态分布图,如下。
具体计算公式为:
 tps = (24小时的PV值*80%)/(24*3600*20%)
     2)简单峰值法
若在每天的某一时段里有很大的访问量,其他时间相对较少,可以用简单峰值法,其实二八法只是简单峰值法的一个特例。
具体计算公式为:
tps =(24小时的PV值)/(峰值时间段中的小时数*3600)
     3)无峰值法
若24小时里的访问量都是平稳波动的,没有峰值,那么可以采用无峰值计算方法,图形如下。
具体计算公式为:
tps= (24小时的PV值)/(24*3600)
1.2.3吞吐量
指软件系统在每单位时间内能处理多少事务/请求/单位数据等,其与tps的近似计算公式为:(单位为秒)
tps = 这段时间内的总样本数/(最后一个请求完成的时刻-第一个请求发起的时刻)
值得注意的是,因为每个请求之间的空闲值也包含在内了,故tps是有误差的,而且tps是个平均值。

需求收集之后,我们已经从性能需求文档中提取出了业务性能测试指标,主要包括PV到TPS的转换以及响应时间要求,接下来我们需要进行进一步的需求分析过程。
1了解系统架构、明确压力流向
     例如统一订购平台的系统架构图:
理解架构图中各个节点的功能与交互关系,通过系统架构图我们能看到压力的入口,即oop应用。请求从oop发起,从udb取到会员数据后,通过dubbo接口,调用订购服务层提供的各种服务,订购服务层所需数据全部从对应cache中取。因此,主干压力流向可得知:
Oop—>udb
Oop—>dubbo—>订购服务层—>cache
然后结合需求文档,根据具体业务场景,确定各分支压力流向,比如有的业务场景需要从pc2取得用户的服务记录,有的业务场景需要付款则需要去帐户中心取得帐户信息,则新增的压力流向如下:
Oop—>dubbo—>pc2—>cache
Oop—>dubbo—>帐户中心
针对每一个测试场景,都要根据系统架构图进行上述分析,明确了各场景的压力流向,即明确了性能测试过程中的监控对象。
监控对象确定后,需要进一步分析明确测试重点,如上例,我们关注的重点是网站的oop应用,因为平台的udb、pc2,crm的服务订购中心,都有各自做过接口性能测试。或者有的应用功能是线上已有的,并没有修改变动,如帐户中心。明确测试重点,将有助于我们进行测试环境相关的测试策略的选择。

2 明确测试环境

2.1 服务器数量确定
根据系统架构图,我们得到了项目中所涉及的环境。众所周知,测试环境越接近生产环境,则测试结果越精确。但通常我们会碰到服务器资源紧张,或者所用应用为外部门的外围环境,搭建方法复杂。此时我们面临两种选择,要么使用功能环境,要么mock掉该环境。建议不要选择前者,可以多个压力流向小的应用公用一台性能服务器。
2.2 服务器配置确定
还是一条不变的原则:测试环境软硬件配置尽量与生产环境保持一致。
机器的性能需求:32位or64位;4核or8核;是否要求同一网段
测试环境软件架构确定(jdk、apache、jboss版本、jvm参数):与线上环境一致,重点关注jvm参数配置,确保与线上一致。
性能测试关注的主要硬件配置及OS参数如下表:
主机/ip
硬件配置
操作系统及参数调整
统一订购层应用服务器
机型
PowerEdge 1950
Linux  2.6.18-92.el5
64位操作系统
CPU
Intel(R) Xeon(R) CPU E5410  @ 2.33GHz * 8
内存10G
网络1000M
应用服务器配置检查中常用的linux指令:
查看机型: dmidecode --type 1|grep "Product Name"
查看CPU: cat /proc/cpuinfo
查看内存:free -mt
查看网卡:
1)ifconfig 检查服务器连接的哪块网卡(ethx)
上图红框内即为当前活动的网卡
2)ethtool ethx 检查网卡详细信息(ethx为ifconfig检查出来的网卡编号,如上图就为eth0)
查看操作系统:
uanme -a 查看所有信息
uname -o, --operating-system    GNU/Linux
      -r, --kernel-release      2.6.18-128.el5(操作系统内核版本)
      -i, --hardware-platform   x86_64(硬件版本)
      -o, --operating-system    x86_64(操作系统版本)
3关键业务数据量分析

3.1 数据量需求确认
1) 数据量是指的性能测试需要考虑的数据总量和数据类型。
例如在offer数据量为30w的DB中查询和在offer数据量为1000w的DB中查询,性能表现一定是不一样的。我们需要考虑,现阶段的数据量等级和未来发展趋势下的数据量等级。有的时候数据量也是程序分支逻辑,所以这点就必须详细考虑了。
2)  存储分布指的数据源的分布情况,是分布式分布还是单台分布;是search分布还是DB分布,等等。例如offer拆分项目的性能测试就需要综合考虑Oracle单表、Oracle16张表、mysql128张表的使用场景
3)  基本要求:测试数据库数据量要与线上数据量保持一个数量级。
3.2 造数据方法确定
根据数量级的需要,可以采用不同的方法,大致有以下几种:
1) 找DBA帮忙导线上/测试库数据;
2) 用datafactory/sql直接插数据库;(查看datafactory文档)
界面如图,具体使用方法问google
3) 用jmeter/LR/ruby等脚本走正常业务流造数据。(查看各脚本录制方法)
3.3划分测试场景、明确测试用例
测试用例的产生需要考虑以下几方面:
1)    测试页面和业务逻辑,也就是业务对应的功能点
注意,性能测试的测试用例也需要专一性,也就是对应单个测试功能点。
因为我们监控的是每个事物的响应时间,功能点需要单一。
2)    压力持续时间
压力持续时间指的是给服务器施加多长时间的压力。
这个时间,我们会结合测试场景,对压力时间做一定的控制。
ü  如果测试的是高峰场景,时间一般最少为1个小时;
ü  如果测试的是稳定性场景,时间一般最少要求8小时;
3)    并发数
不要混淆并发和TPS的关系。
并发数指的是同时有多少用户(线程)在对服务器施加压力,是量化的给服务器的压力;而TPS指的是服务器每秒钟能够处理的事物数,是服务器处理能力的体现。

性能测试需求分析 PV,响应时间、QPS、TPS相关推荐

  1. QPS/TPS/并发量/系统吞吐量

    1.QPS QPS Queries Per Second 是每秒查询率 ,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数,也即是 ...

  2. 性能测试需求分析 业务PV量,响应时间、QPS、TPS

    一. 性能测试需求分析 1.1      性能测试需求内容 性能测试需求应包括以下内容: a)    测试场景及用例,用例访问URL: b)   目标接口方法的入参.出参: c)    外部依赖的服务 ...

  3. 【网络基础】qps | tps | pv | uv

    PV PV即page view.页面浏览量 用户每次访问站点中的每个页面都会被记录一次. 用户多次更新同一页面,累计了访问量. 访问一次,累计一次. UV UV是Unique visitor,是独立的 ...

  4. 阿里云云盾抗下全球最大DDoS攻击(5亿次请求,95万QPS HTTPS CC攻击) ,阿里百万级QPS资源调度系统,一般的服务器qps多少? QPS/TPS/并发量/系统吞吐量...

    阿里云云盾抗下全球最大DDoS攻击(5亿次请求,95万QPS HTTPS CC攻击) 作者:用户 来源:互联网 时间:2016-03-30 13:32:40 安全流量事件https互联网资源 摘要:  ...

  5. QPS/TPS/并发量/系统吞吐量的概念

    2019独角兽企业重金招聘Python工程师标准>>> 我们在日常工作中经常会听到QPS/TPS这些名词,也会经常被别人问起说你的系统吞吐量有多大.这个问题从业务上来讲,可以理解为应 ...

  6. QPS/TPS/并发量/系统吞吐量概念和公式

    1.概念 我们在日常工作中经常会听到QPS/TPS这些名词,也会经常被别人问起说你的系统吞吐量有多大.一个系统的吞度量(承压能力)与request对CPU的消耗.外部接口.IO等等紧密关联,单个req ...

  7. redis mysql qps_测算Redis处理实际生产请求的QPS/TPS

    测算Redis处理实际生产请求的QPS/TPS Benchmark工具 redis发布版本中自带了redis-benchmark性能测试工具; 示例: 使用50个并发连接,发出100000个请求,每个 ...

  8. 性能测试需求分析有哪些?怎么做?

    目录 性能测试必要性评估 常见性能测试关键评估项如下: 性能测试工具选型 性能测试需求分析 性能测试需求评审 性能测试需求分析与传统的功能测试需求有所不同,功能测试需求分析重点在于从用户层面分析被测对 ...

  9. 如何提高系统的吞吐量(QPS/TPS)

    一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗.外部接口.IO等等紧密关联.单个reqeust 对CPU消耗越高,外部系统接口.IO影响速度越慢,系统吞吐能力越低,反 ...

最新文章

  1. 什么是“缓存友好”代码?
  2. vim中搭建与sourceinsight类似功能
  3. php redis 扩展 常用方法
  4. Java zip解压,并遍历zip中的配置文件 .cfg或.properties
  5. 架构设计--仅是软件开发之第二大影响力?!
  6. 编码 GBK 的不可映射字符
  7. Media Player 嵌套网页中播放上传视频记录
  8. linux 物理内存 查看,Linux查看物理内存信息
  9. 9款超级好用的在线PDF工具!
  10. 离散数学主析取及主合取范式
  11. 【知识点】patch补丁文件格式
  12. JS 逆向之 Hook,吃着火锅唱着歌,突然就被麻匪劫了!
  13. 关于ksps(A/D转换速率单位)
  14. Smart210学习记录-------内存初始化
  15. 【SDOI2008】Sandy的卡片 DP
  16. 快手的扫描登录网页端隐藏得够深得
  17. EtherCAT (学习笔记)
  18. 苹果16g不够用怎么办_孩子不够自信怎么办?父母学会用这4个方法,孩子长大更优秀自信...
  19. Apache Log4j2漏洞复现
  20. 常见电脑硬件故障有哪些?如何解决?~~~CPU故障

热门文章

  1. 系统调用原理及详细过程
  2. 手机端虚拟键盘弹出使界面布局混乱解决方法
  3. 关于上海居住证-我们不得不说的实情![转]
  4. 自定义ToolBar的使用
  5. 差网络模拟工具---clumsy
  6. Python · 实现鼠标绘画
  7. 考研英语二语法知识点 1.2简单句的核心变化
  8. 林世霖. linux环境编程图文指南,linux环境编程图文指南
  9. tensorflow中Dataset.shuffle函数的buffer size的含义解读
  10. java 秒表_Java的秒表类