响应时间

Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件。相比Loadrunner而言，JMeter小巧轻便且免费，逐渐成为了主流的性能测试工具，是每个测试人员都必须要掌握的工具之一。 本文为JMeter性能测试完整入门篇，从Jmeter下载安装到编写一个完整性能测试脚本、最终执行性能测试并分析性能测试结果。 运行环境为Windows 10系统，JDK版本为1.8，JMeter版本为3.3。 Jmeter安装 2.1 JDK安装 由于Jmeter是基于java开发，首先需要下载安装JDK （目前JMeter只支持到Java 8，尚不支持 Java 9） 官网下载地址： http://www.oracle.com/technetwork/java/javase/downloads/index.html 选择Java SE 8u151/ 8u152，点击JDK下载 这里写图片描述 安装下载的JDK 配置系统环境变量 2.2 JMeter安装 官网下载地址： http://jmeter.apache.org/download_jmeter.cgi 下载最新JMeter 3.3版本：apache-jmeter-3.3.zip 这里写图片描述 下载完成后解压zip包 启动JMeter 双击JMeter解压路径（apache-jmeter-3.3\bin

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。 正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。 一些测试方法主要分以下几种： 压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。 Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。 Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。 另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准

转自 吞吐量（TPS）、QPS、并发数、响应时间（RT）概念 - 付金波的博客园 - 博客园 吞吐量(tps) 吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。 每秒查询率(qps)

性能测试报告 Performance Test Report 项目 XXX项目 二期 版本 V1.00 作者 dayu 日期 2019.9.31 1. 测试概述 1.1 测试目标 描述本次测试的意义和目标 本次测试的目的在于探查 XXX项目 二期重构环境的系统业务处理性能，以及在高负载情况下的系统表现。 1.2 指标和术语 描述本次测试中涉及到的性能指标术语 术语 释义 并发数 测试时同时系统发出事务请求的数量，并发线程数用以模拟同时与系统建立连接的用户。 TPS （每秒事务数） 在每秒时间内系统可处理完毕的事务数。 TPS 很大程度体现系统性能能力。 错误率 经系统处理的事务出现错误的概率，对应着实际用户使用系统功能失败的情况。理想情况下错误率应保持极低水平。 资源占用率 服务器端各关键资源的使用比例，用于衡量系统硬件能力 2. 环境、工具 列出本次测试所涉服务器、客户机和测试工具 2.1 测试环境 服务器： 应用 机器 CPU、内存配置 API ip地址 16 核 CPU 、内存 16G MYSQL ip地址 16 核 CPU 、内存 16G 客户机： 操作系统 CPU 内存 Windows10 专业版 I3- 4170 3.70GHZ 8G 2.2 测试工具 核心工具 版本 备注 Jmeter 3.3 提供并发请求能力 PerfMon Metrics Collector 2

SLA服务等级协议 Service Level Agreement，包括： 服务目录：如feed流（推荐信息流） 服务可用性：99.9，99.99等 服务故障恢复时间：多长时间可以恢复如10分钟 依赖性 强依赖：挂掉后用户无法使用 弱依赖：挂掉后用户可以使用，但体验不佳 核心依赖：挂掉后用户体验损伤很大 非核心依赖：挂掉后用户体验基本无损 核心概念 并发数：同一时刻处理的请求数，并发能力受限于worker数量、cpu、memory等 吞吐量QPS：每秒钟处理的请求数 响应时间：处理一个请求的响应时间 avg：平均响应时间 pct99: 99%的请求相应时间 目标 在任何情况下，尽可能保证SLA 准则：Design for failure，墨菲定律，自动化 产品核心指标 新增，留存，活跃，营收 故障预防 重试 解决下游单机/网络抖动等问题，提高接口可用性。 重试一次会导致两倍流量，会引起雪崩。 原则是核心从宽，非核心从严。 核心依赖：1次重试+10%比例限制。非核心依赖：0次重试。 合理的超时+合理的重试+适当的缓存策略。超时timeout = 2 * time_pct99.5 熔断 为了保护下游，防止无效等待和占用资源，可以引入熔断，即一段时间内直接返回不去请求。 兜底 服务异常时，通过策略尽可能保证用户体验。如增加默认数据，Redis，local cache（热内容，上已刷等）

一、API网关 微服务架下，服务之间容易形成网状的调用关系，这种网状的调用关系不便管理和维护，这种场景下API网关应运而生。作为后端服务的入口，API网关在微服务架构中尤其重要，在对外部系统提供API入口的要求下，API网关应具备路由转发、负载均衡、限流熔断、权限控制、轨迹追踪和实时监控等功能。 目前，很多微服务都基于的Spring Cloud生态构建。Spring Cloud生态为我们提供了两种API网关产品，分别是Netflix开源的Zuul1和Spring自己开发的Spring Cloud Gateway（下边简称为Gateway）。Spring Cloud以Finchley版本为分界线，Finchley版本发布之前使用Zuul1作为API网关，之后更推荐使用Gateway。 虽然Netflix已经在2018年5月开源了Zuul2，但是Spring Cloud已经推出了Gateway，并且在github上表示没有集成Zuul2的计划。所以从Spring Cloud发展的趋势来看，Gateway代替Zuul是必然的 1.1 Zuul1简介 Zuul1是Netflix在2013年开源的网关组件，大规模的应用在Netflix的生产环境中，经受了实践考验。它可以与Eureka、Ribbon、Hystrix等组件配合使用，实现路由转发、负载均衡、熔断等功能

原文转自： https://blog.csdn.net/lovesoo/article/details/78579547 Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件。相比Loadrunner而言，JMeter小巧轻便且免费，逐渐成为了主流的性能测试工具，是每个测试人员都必须要掌握的工具之一。 本文为JMeter性能测试完整入门篇，从Jmeter下载安装到编写一个完整性能测试脚本、最终执行性能测试并分析性能测试结果。 运行环境为Windows 10系统，JDK版本为1.8，JMeter版本为3.3。 2. Jmeter安装 2.1 JDK安装 由于Jmeter是基于java开发，首先需要下载安装JDK （目前JMeter只支持到Java 8，尚不支持 Java 9） 1. 官网下载地址： http://www.oracle.com/technetwork/java/javase/downloads/index.html 2. 选择Java SE 8u151/ 8u152，点击JDK下载 3. 安装下载的JDK 4. 配置系统环境变量 2.2 JMeter安装 官网下载地址： http://jmeter.apache.org/download_jmeter.cgi 下载最新JMeter 3.3版本：apache-jmeter-3.3.zip

如何减少接口响应时间 Premature optimization is the root of all evil. 　 — Donald Knuth 对于程序优化，我一直采取保守的态度，除非万不得已。但是随着业务的不断发展，程序越来越复杂，代码越写越多，优化似乎是终有一天会到来的事情。 那么对于一个典型的后台服务接口，我们可以从那些方面入手进行优化呢？ 接口拆分 接口垂直拆分 垂直拆分可以简单理解为微服务化，把一个大而复杂的服务拆分成多个相互独立，职能单一的服务，单独部署。 更细粒度拆分的好处是，能对某个具体的微服务进行特殊优化，以最大的投入产出比来解决整个服务的性能。 垂直拆分还有一个好处是，对于非必须的接口，可以很方便的进行降级处理，把坏影响隔离到核心逻辑外部。 最容易想到的优化办法是把某个对整体性能有决定性影响的微服务接口进行水平扩容。 注意: 拆分后必定会增加外部接口调用，多少会有些额外开销，但是对于有限几个调用，拆分的还是值得的。 接口水平拆分 这里说的水平拆分一定不是把一个接口部署更多份，因为这样只能解决接口的容量问题，但是不能减少接口的响应时间。 水平拆分可以简单理解成mapreduce模型，把整个计算逻辑或者数据平均分配到集群中的N个服务器去，然后由一台机器去并发调用并做结果合并。 理论上这种方式能把响应减少到 1/N+合并+调用开销 的时间。 注意：

　 上图非常清楚的表述了单实例模式下用户提交操作的处理过程，从图中可以看出正常情况下log file sync事件的大部分时间被log file parallel write占据，除此之外，还有一部分时间消耗在cpu调度上面，如下图： 从上图可以看出，如果cpu资源紧张也会造成log file sync等待时间的延长。 来自吕大师（vage ）对log file sync等待事件优化的总结， 供各位puber们学习参考： 1、Log File Sync是从提交开始到提交结束的时间。Log File Parallel Write是LGWR开始写Redo File到Redo File结束的时间。明确了这一点，可以知道，Log file sync 包含了log file parallel write。所以，log file sync等待时间一出，必先看log file parallel write。如果log file sync平均等待时间（也可称为提交响应时间）为20ms，log file parallel write为19ms，那么问题就很明显了，Redo file I/O缓慢，拖慢了提交的过程。 2、 Log File Sync的时间不止log file parallel write。服务器进程开始提交，到通知LGWR写Redo，LGWR写完Redo通知进程提交完毕

在日常的工作中经常会讲到吞吐量、并发量等概念，查询了下相关资料，在这里记录下对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科。 响应时间(RT) 　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 吞吐量(Throughput) 吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）