测试学习8-1_关于并发用户数,响应时间、系统吞吐量之间的关系,下列说法不正确的是-CSDN博客

本文链接：https://blog.csdn.net/weixin_43999171/article/details/102818373

性能测试

性能测试的关注点

web类应用和手机端应用，一般以终端用户感受到的端到端响应时间来描述系统的性能
非交互式应用，如银行后台处理系统，响应时间关注的更多的是事件处理的速度，以及单位时间的事件吞吐量

衡量软件性能的四个维度

终端用户
软件设计开发人员
系统运维人员
性能测试人员

终端用户眼中的软件性能

希望业务越快越好

表现为用户进行业务操作时的主观响应时间，时间越短体验越好
这个响应时间是终端用户对系统性能最直观印象，包括了系统响应时间和前端展现时间
系统响应时间：反应的是系统能力，可以细分为应用系统处理时间、数据库处理时间和网络传输时间
前端展现时间：取决于用户端的处理能力
从这个角度看，可以非常容易理解性能测试分为后端(服务器端)和前端(浏览器端)性能测试

系统运维人员眼中的软件性能

追求系统整体的容量和稳定

软件性能除了包括单个用户响应时间外，更要关注大量用户并发访问时的负载，以及可能的更大负载情况下系统健康状态、并发处理能力、当前部署地系统容量、可能地系统瓶颈、系统配置层面地调优、数据库调优以及长时间运行稳定性和可扩展性
目前，有些系统为了能够承载更多地并发用汉语，往往会牺牲等待时间而引入预期地等待机制(如火车票排队)

软件设计开发人员眼中的软件性能

以性能工程视角关注实现过程的性能

软件性能关注的是性能相关的设计和实现细节，几乎涵盖了软件设计和开发的全过程，不仅仅是性能测试阶段要考虑地问题，而是整个软件研发生命周期都要考虑地内容，把围绕性能相关地活动称为性能工程
通常包括算法设计、架构设计、性能最佳实践、数据库相关、软件性能可测试性五大方面
1，算法设计包含的点
核心算法设计与实现是否高效
必要时，设计上是否采用buffer机制以提高性能，降低I/O
是否存在潜在的内存泄露
是否存在并发环境下的线程安全问题
是否存在不合理的线程同步方式
是否存在不合理的资源竞争
2，架构设计包含内容
站在整体系统角度，是否可以方便进行系统容量和性能扩展
应用集群的可扩展性是否经过测试和验证
缓存集群的可扩展性是否经过测试和验证
数据库的可扩展性是否经过测试和验证
3，性能最佳实践包含内容
代码实现是否遵守开发语言的性能最佳实践
关键代码是否在白盒级别进行性能测试
是否考虑前端性能优化
必要时是否采用数据压缩传输
对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序
4，数据库相关的点
数据库表设计是否高效
是否引入必要的索引
SQL语句的执行计划是否合理
SQL语句除了功能是否要考虑性能要求
数据库是否需要引入读写分离机制
系统冷启动后，缓存大量不命中时，数据库承载的压力是否超负荷
5，软件性能可测试性包含的点
是否为性能分析提供必要的接口支持
是否支持高并发场景下的性能打点
是否支持全链路的性能分析
需要注意的是，开发人员一般不需要关注系统部署级别的性能，如软件运行目标操作系统的调优、应用服务器的参数调优、数据库的参数调优、网络环境的调优
系统部署级别的性能测试，目前一般在系统性能测试阶段或者系统容量规划阶段，由性能测试人员、系统架构师、数据库管理员DBA协作完成

性能测试人员眼中的软件性能

全面考量、各个击破

性能测试工程师关注的是算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性五大方面
性能测试人员既能准确把握软件的性能需求，又要能够准确定位引起'不好'性能表现的制约因素和根源，并提取相应的解决方案
性能测试工程师，具有的能力：
性能需求的总结和抽象能力
根据性能测试目标，精准的性能测试场景设计和计算能力
性能测试场景和性能测试脚本的开发和执行能力
测试性能报告的分析解读能力
性能瓶颈的快速排查和定位能力
性能测试数据的设计和实现能力
对互联网产品，全链路压测的设计和执行能力，能够和系统架构师一起处理流量标记、影子数据库等技术设计能力
及其宽广的知识面，既要有面：系统架构、存储架构、网络架构等全局知识，又要有点：SQL语句执行计划调优、JVM垃圾回收机制、独傲县城常见问题等

衡量软件性能三个常用指标：并发用户数、响应时间、系统吞吐量

并发用户数

可以指实际的并发用户数，也可以指服务端并发数量

是性能需求与测试最常用，也是最重要的指标之一，包含了业务层面和后端服务器层面两层含义
业务层面的并发用户数：指实际使用系统的用户总数，单个指标不能反映系统实际承载能力，还需要结合用户行为模型才能得到系统实际承载的压力
后端服务器层面的并发用户数：指同时向服务器发送的请求数量，直接反应系统实际承载的压力
“同时向服务其发送请求的数量”就是服务器层面的并发用户数，这个指标同时取决于业务并发用户数和用户行为模式，而且用户性能模式占比较大
因此。分析得到准确的用户行为模式，是性能测试中关键一环，是除了获取性能需求外，最困难的工作
获取用户行为模式，主要有两种方法：
1，对于已经上线的系统来说，往往采用日志分析法获取用户行为统计和峰值并发量等重要信息
2，对于未上线全心系统来说，通常做法是参考行业中类似系统的统计信息来建模，然后分析

响应时间

响应时间反映了完成某个具体操作所需要的时间，标准定义是，应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间，是用户视角软件性能的主要体现

响应时间，分为前端展现时间和系统响应时间两部分。前端时间又称呈现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间；而系统响应时间，又可以进一步划分为web服务器时间、应用服务器时间、数据库时间以及各服务器间通信地网络时间
除非又针对前端的性能测试与调优，软件性能测试一般更关注服务器端。服务器端响应时间概念非常清晰、直接，就是指从请求发出到处理完成的时间；但是前端时间的定义，有一些歧义
虽然前端时间在一定程度上取决于客户端的处理能力，但是开发人员会使用一些编程的技巧在数据尚未完全接受时呈现数据，即现在普遍采用提前渲染技术，使得用户实际感受的响应时间通常小于标准定义时间
严格来说，响应时间应该包含两层含义：技术层面的标准定义和基于用户主管感受时间的定义，在性能测试过程中，我们应该使用哪个层面的含义主要取决于性能测试的类型；对于软件服务器端的性能测试肯定采用标准定义，对于前端性能评估，应该采用用户主管感受时间的定义

系统吞吐量

最能直接体现软件系统负载承受能力的指标，需要注意的是，所有吞吐量的讨论都必须以“单位时间”作为基本前提，更贴切的说法是吞吐率，因为吞吐率=吞吐量/单位时间

对于性能测试而言，通常采用 request/second, pages/second, bytes/second, 来衡量吞吐量，从业务角度来说，吞吐量也可以用单位时间的业务处理数量来衡量
不同方式表达的吞吐量说明不同层次的问题：
bytes/second和pages/second表示的吞吐量，主要受网络设置，服务器架构，应用服务器制约
requests/second表示的吞吐量，主要受应用服务器和应用本身实现的制约
需要注意的是：虽然吞吐量可以反映服务器承受负载的情况，但是不同并发用户数场景下，即使系统有相近的吞吐量，得到的系统性能瓶颈也会相差很远，如100个用户，每个用户1s一个请求和1000个用户，10s一个请求，吞吐量一致，但是性能拐点不一致
这就要求性能测试场景的指标，不是单个，需要根据实际情况组合并发用户数、响应时间这两个指标

实际生产中，吞吐量指标选择

考察HTTP或者业务层面，选择requests/second, pages/second
考察系统层面或者网络层面，可以选择bytes/second，即网卡每秒接收/发送字节数

工具选择

后端性能工具推荐loadrunner和jmeter，前端性能工具推荐webpagetest和Yslow

性能测试的基本方法与应用领域

关键是理解方法的本质和内涵

并发用户数、响应时间、系统吞吐量之间的关系

当系统并发用户数较少时，系统吞吐量较低，系统处于空闲状态，这个阶段称之为空闲区间
当系统整体负载并不是很大时，随着系统并发用户数增长，系统的吞吐量也会随着线性增长，这个阶段称之为线性增长区间
随着系统并发用户数的进一步增长，系统测处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长，相应的，系统地吞吐量并不会随着并发用户数地增长而继续呈现线性增长，这个阶段称为系统拐点
随着系统并发用户数增长，系统处理能力达到过饱和状态，此时入宫继续增加并发用户数，最终所有用户响应时间都会变得很长，相应地，系统整体吞吐量会降为0，系统处于被压垮的状态，这个阶段称为过饱和区间
理解了主要性能指标之间的约束关系，才能在实际性能测试实践中有的放矢的性能测试场景，如：后端性能测试的测试负载一般只会设计在线性增长区间内，压力测试的测试负载，设计在系统拐点上下，甚至是过饱和区间

常用的七种性能测试方法

1，后端性能测试

后端性能测试，是通过性能测试工具模拟大量用户的并发用户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试手段

这里的性能指标，除了包括并发用户数、响应实践和系统吞吐量外，还应该包括各类资源的使用率，如系统级的CPU占用率，内存使用率，磁盘I/O，网络I/O
由于需要模拟的并发用户数，通常是几百到几百万数量级，所以选择性能测试工具，一定不是基于GUI的，而是采用基于协议的模拟方法，也就是模拟用户在GUI操作过程中实际向后端服务发起的请求
后端性能测试的场景设计主要包括以下两种方式：
基于性能需求目标的测试验证
探索系统的容量，并验证系统容量的可扩展性

2，前端性能测试

通常来说，前端性能关注的是浏览器端的页面渲染实践、资源加载顺序、请求数量、前端缓存使用情况、资源压缩等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优化，最终达到优化终端用户在浏览器端使用体验的目的
雅虎前端优化

目前业界普遍采用的前端测试方法，是雅虎前端团队总结的7大类35条前端优化原则
其中比较典型的有：
减少http请求次数：http请求数量越多，执行过程耗时越长，可以采用合并多个图片到一个图片文件来减少请求，也可以将多个脚本文件合并成单一脚本文件
减少DNS查询次数：DNS作用主要是将URL转化为实际服务器主机IP地址，实现原理是分级查找，需要消耗20~100ms时间，所以一方面要加快单次查找时间，另一方面要减少一个页面中资源使用多个不同域的情况
避免页面跳转：页面跳转相当于又打开了一个页面，耗费时间较长，尽量避免页面跳转
使用内容分发网络：使用CDN相当于对静态内容做了缓存，并把缓存内容放在网络供应商(ISP)机房，用户根据就近原则到ISP机房获取被缓存的静态资源，大幅提高性能
Gzip压缩传输文件：压缩文件可以减少文件大小，进而可以从网络传输使劲按层面来减少响应时间

3，代码级性能测试

是指在单元测试阶段对代码的时间性能和空间性能进行必要的测试和评估，以防止底层代码的效率问题在项目后期才被发现

需要在项目早期，对一些关键算法进行代码级别的性能测试，防止此类代码存在性能问题，遗留到最后的系统测试中
代码级性能测试并不是严格的测试工具，通常做法是改造现有的单元测试框架
常用的改造方法是：
1，将原本执行一次的单元测试用例连续执行N次，N取值通常是2000-5000
2，统计执行N次需要的平均时间，如果平均时间较长(单次函数调用时间较长)，比如已经达到了秒级，通常情况下被测函数实现逻辑一定需要优化(因为函数执行时间往往是毫秒级)

4，压力测试

通常指后端压力测试，一般采用后端性能测试方法，不断对系统施加压力，并验证系统处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态的主要瓶颈点。所以，压力测试往往被用于系统容量规划的测试
在有些情况下，执行压力测试时，会故意在临界饱和状态基础上继续施加压力，直至系统完全瘫痪，观察这个期间系统的行为，然后逐渐减小压力，观察瘫痪的系统是否可以自愈

5，配置测试

主要用于观察系统在不同配置下的性能表现，通常使用后端性能测试方法：

1，通过性能基准测试(Performance Benchmark)建立性能基准下(Performance Baseline)
2，在此基础上，调整配置
3，基于同样的性能基准测试，观察不同配置条件下系统性能的差异，根本目的是要找到特定压力模式下的最佳配置
需要注意的是：配置是一个广义的概念，包含多层面的配置

6，并发测试

指在同一时间，同时调用后端服务，期间观察被调用服务在并发情况下的行为表现，旨在发现资源竞争、资源死锁之类问题

谈到并发测试，不得不谈“集合点并发”概念，源于HP的LoadRunner，目前已被广泛使用
为了达到准确控制后端服务并发数的目的，需要让某些并发用户数到达该集合点时，先处于等待状态，直到该集合的全部并发用户都到达时，再一起向后端服务发起请求
所以，在实际项目中，建议在要求的并发数上进行适当放大，比如要求的并发数是100，那么集合点并发数可以设置为120

7，可靠性测试

是验证系统在常规负载模式下长期运行的稳定性
虽然可靠性测试在不同公司叫法不同，但是本质可以通过长时间模拟真实的系统负载来发现系统潜在的内存泄露、连接池回收等问题

由于真实环境下的实际负载，会有高峰和低谷的交替变化(企业级应用，白天是高峰晚上是低谷)，为了尽可能模拟真实负载情况，会每i2小时模拟一个高峰负载，两个高峰负载中间会模拟一个低峰负载，依次循环3-7天，形成一个类似波浪形的系统测试负载曲线
然后，用这个波浪形测试负载模拟真实的系统负载，完成可靠性测试，同样可靠性测试也会持续3-7天