响应时间

什么是基准测试 数据库的基准测试是对数据库的性能指标进行定量的、可复现的、可对比的测试。 基准测试与压力测试 基准测试可以理解为针对系统的一种压力测试。但基准测试不关心业务逻辑，更加简单、直接、易于测试，数据可以由工具生成，不要求真实；而压力测试一般考虑业务逻辑(如购物车业务)，要求真实的数据。 基准测试的作用 对于多数Web应用，整个系统的瓶颈在于数据库；原因很简单：Web应用中的其他因素，例如网络带宽、负载均衡节点、应用服务器（包括CPU、内存、硬盘灯、连接数等）、缓存，都很容易通过水平的扩展（俗称加机器）来实现性能的提高。而对于MySQL，由于数据一致性的要求，无法通过增加机器来分散向数据库写数据带来的压力；虽然可以通过前置缓存（Redis等）、读写分离、分库分表来减轻压力，但是与系统其它组件的水平扩展相比，受到了太多的限制。 而对数据库的基准测试的作用，就是分析在当前的配置下（包括硬件配置、OS、数据库设置等），数据库的性能表现，从而找出MySQL的性能阈值，并根据实际系统的要求调整配置。 基准测试的指标 常见的数据库指标包括： TPS/QPS：衡量吞吐量。 响应时间：包括平均响应时间、最小响应时间、最大响应时间、时间百分比等，其中时间百分比参考意义较大，如前95%的请求的最大响应时间。 并发量：同时处理的查询请求的数量。 基准测试的分类 对MySQL的基准测试

软件性能术语 软件性能的主要术语 用户数 注册用户数（系统用户数） 在线用户 并发用户 虚拟用户 事务（TPS） 响应时间 QPS PV（Page View） 思考时间 吞吐量（一般指字节） 吞吐率（一般指字节） 性能计数器 软件性能非主要术语 集合点 迭代 步调 每秒连接数 软件性能的主要术语 用户数 有时会看到下面这样的描述：一个系统注册用户达到6000万人，其中每小时的活跃用户大概在60万人左右。这段描述介绍了两个信息，第一个信息：6000万人指的是注册用户，第二个信息：60万人指的是真实在线用户。 注册用户数（系统用户数） 注册用户是存在于系统数据库表中的基础数据。这部分用户是指系统所拥有的所有用户群体。这些用户是不会全部对系统造成压力的，唯一的压力就是这些用户占用了系统的存储，影响了数据库的容量。 在线用户 在线用户是真实产生压力的用户，这些用户是压力的根源，也就是系统要能够支持这么多人同时在线业务。 同时在线用户数：在一定的时间范围内，最大的同时在线用户数量 同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间 并发用户 在线用户是真实的用户，但不是所有的在线用户都会在系统上操作，可能有些用户在浏览网页、有些用户在做业务、有些用户只是开着浏览器。这时在线用户对系统产生压力的用户只有一部分，而这部分用户就是在线用户中的有效并发用户。

性能测试主要看哪几方面？ 1. 响应时间 ： 完成一个业务所需要的时间 2. 吞吐量： 单位时间处理的业务数量 3. 资源利用率 ： 完成业务需要的开销 （ CPU, 内存，IO) 性能的难点 用户总希望发最小的代价取得最大的收益，实际上一旦确定了架构，性能也就确定了 　　- 如果遵守规范体系能够达到默认架构的性能 　　- 大多数的开发会违背架构，拖后腿 性能测试模型 1. 做单用户的业务串行测试 ： 评估单独业务的相应时间 2. 多用户的并发测试：了解相应时间的转折点： - 队列 - 资源不足 - 处理能力的峰值 模型结论：（所有系统都遵守） 1. 响应时间随着负载的上升先稳定后上升，并且越来越快 A点：响应时间开始变长的点 为什么响应时间开始变长？ 当到达A点说明负载导致了队列的产生 B点： TPS开始下降 B点处理能力已经不能完全占用资源，开始下降了 C点： 响应时间超过用户接受范围 C点响应时间超时 系统在A点，说明负载小 系统在B点，说明达到系统最佳在线用户 系统在C点，说明系统不能用 正常系统应该一直在A->B之间，最好不超过B 性能瓶颈： 99%都是数据库 调优：ABC三点右移，说明调优成功 系统如果慢了，应该怎么处理？ 有监控系统就看监控系统，没有监控系统就用命令，查看CPU, 内存，IO，network的信息 命令： top 1. 查看cpu的使用情况

1.1计算机的分类和其特性 计算机通常分为三类：个人计算机 服务器 嵌入式计算机 个人计算机：给单个用户提供服务 服务器：给多个用户运行大型程序提供服务 嵌入式计算机：嵌入到其它设备中的计算机 执行已经预定的一个或者一组程序 1.2后PC时代 个人移动设备PMD ： 智能手机 平板电脑等 1.3 在20世界六七十年代 限制计算机性能的主要是内存 多核微处理器：在一个集成电路上面有多个核的微处理器 一个程序的性能主要取决于：1.算法 2.编译程序 3.计算机执行的机器指令的有效性 2 计算机系统结构的八个伟大思想 2.1 面向摩尔定律的设计 摩尔定律 每隔18-24个月 集成电路上的芯片数目将翻一番 2.2 使用抽象化设计 上层只能看到下层的抽象模型 而看不到细节 2.3 并行 计算机并行操作 2.4 流水线 并行的一种特例 2.5 预测 在预测错误的情况下代价不大且预测准确率较高的情况下采用预测 2.6 存储器层次 小而快的再上 大而慢的在下 2.7 使用冗余 添加冗余部件 提高系统的可靠性 2.8 加速大概率事件 加速大概率事件远比优化小概率事件效果大 3 程序概念入门 应用软件 系统软件 硬件 系统软件最重要的是：操作系统 和 编译程序 操作系统：用户软件和硬件之间的接口 为用户提供各种服务和监控功能 操作系统的主要作用：处理简单的输入和输出 分配内存和外存

影响一个系统性能的方方面面 一个web应用不是一个孤立的个体，它是一个系统的部分，系统中的每一部分都会影响整个系统的性能 常用的性能评价/测试指标 响应时间 提交请求和返回该请求的响应之间使用的时间，一般比较关注平均响应时间。 常用操作的响应时间列表： 操作 响应时间 打开一个站点 几秒 数据库查询一条记录（有索引） 十几毫秒 机械磁盘一次寻址定位 4毫秒 从机械磁盘顺序读取1M数据 2毫秒 从SSD磁盘顺序读取1M数据 0.3毫秒 从远程分布式换成Redis读取一个数据 0.5毫秒 从内存读取1M数据 十几微妙 Java程序本地方法调用 几微妙 网络传输2Kb数据 1微妙 并发数 同一时刻，对服务器有实际交互的请求数。 和网站在线用户数的关联：1000个同时在线用户数，可以估计并发数在5%到15%之间，也就是同时并发数在50~150之间。 吞吐量 对单位时间内完成的工作量(请求)的量度 关系 系统吞吐量和系统并发数以及响应时间的关系： 理解为高速公路的通行状况： 吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费）， 并发数是高速公路上的正在行驶的车辆数目， 响应时间是车速。 车辆很少时，车速很快。但是收到的高速费也相应较少；随着高速公路上车辆数目的增多，车速略受影响，但是收到的高速费增加很快； 随着车辆的继续增加，车速变得越来越慢，高速公路越来越堵，收费不增反降；

参考文章： https://blog.csdn.net/u012111923/article/details/80705141 1.1 JDK安装 ··由于Jmeter是基于java开发，首先需要下载安装JDK （目前JMeter只支持到Java 8，尚不支持 Java 9） ··- 1. 官网下载地址： http://www.oracle.com/technetwork/java/javase/downloads/index.html ··- 2. 选择Java 8，下载 JMeter安装 官网下载地址： http://jmeter.apache.org/download_jmeter.cgi 下载最新JMeter 版本：apache-jmeter-*.zip； 下载后解压 -在bin目录下找到jmeter.bat即可快速启动 中文只需要在jmeter。properties中配置 language = zh_cn 即可 聚合报告参数详解： Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值 #Samples：请求数——表示这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100 Average：平均响应时间——默认情况下是单个 Request

Jmeter实现混合场景交易占比配置： 1. 用吞吐量控制器来实现混合交易占比（此前用过：1. 随机数+IF控制器 2.迭代次数+IF控制器取余 这二种方法测试出来的混合场景TPS呈规律性下降；3.用混合场景的平均响应时间+交易占比推算各个交易的并发数 来测试混合场景，此方法虽与实际的交易量占比略有偏差，但受环境影响较大，比如：交易的平均响应时间不稳定，又得重新计算，不推荐） 来源： https://www.cnblogs.com/wwwricky/p/11316072.html

 最近性能压测执行过程中，经常看到很多测试人员执行性能测试，要寻找拐点，但是效率太低，本文就介绍下，如何高效确定性能测试拐点  所谓性能测试拐点，就是指并发用户达到一定数量，平均响应时间递增，TPS不增反降，报错率递增，当前并发用户就是该测试案例的拐点    寻找拐点的意义就是当前并发用户下，系统的平均响应时间、TPS、报错率是否满足性能要求，如果满足，该并发用户就是满足用户需求下所能承受的最大并发用户数，在去考虑并发用户是否满足系统用户需求，可以结合系统总用户数、在线用户数去判断，他们的关系大致如下： 在线用户数=系统总用户数*20% 并发用户数=在线用户数*30% 比如系统总用户数是10000，则在线用户数就是2000，并发用户数就是600 一、脚本开发 1. 首先给大家介绍如何开发高效执行的性能测试脚本，目前多数用户都是分不同并发用户单次执行，该方法执行效率低，并且不方便数据比对，如下 首先开发好测试案例，然后把案例复制成多个，每个线程修改线程数、用例名称即可，如下所示，修改用例名称和线程数对应，这样生成的测试结果就会区分不同并发下同一个案例的响应时间，方便比对 如果有多个接口实现了一个用例，则需要把所有接口放置在事务控制器下即可，这样就能生成一个汇总结果(统计多个请求的响应时间、tps等值) 最后在测试计划记得勾选独立运行每个线程组选项，勾选该选项的意义就是依次并发执行10