压力/负载/性能测试的异同
在产品研发过程中，常常会混淆压力/负载/性能测试这三者之间的区别，这三种测试到底有什么不同呢？
压力测试（Stress Testing），也称为强度测试，通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。压力测试需要确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。
负载测试（Load Testing）通常被定义为给被测系统加上它所能操作的最大任务数的过程，负载测试有时也会被称为“容量测试”或者“耐久性测试/持久性测试”，其目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。对于WEB应用来讲，负载则是并发用户或者HTTP连接的数量。负载测试通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
性能测试（Performance Testing）的目的不是去找系统Bugs，而是排除系统的性能瓶颈，并为回归测试建立一个基准。而性能测试的操作，实际上就是一个非常小心受控的测量分析过程：“运行负载试验->测度性能->调试系统”。在理想的情况下，被测应用在这个时候已经是足够稳定，所以这个过程得以顺利进行。性能测试还有另一个目标就是建立一组被测系统的基准数据。应用在网络上的性能测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。
虽然三种测试的目的截然不同，但其测试操作的环节都是基本一致的，因此一次测试过程中完全可以包含性能测试、负载测试、压力测试三个方面的内容，所使用的测试工具往往大同小异。
主流压力/负载/性能测试工具推荐
市面上流行的压力/负载/性能测试工具多是来自国外，同时由于开发的目的和侧重点不同，其功能也有很大差异，下面就为您简单介绍10款目前最常见的测试产品。
1. LoadRunner
LoadRunner是一种预测系统行为和性能的负载测试工具，通过模拟实际用户的操作行为进行实时性能监测，来帮助测试人员更快的查找和发现问题。LoadRunner适用于各种体系架构，能支持广泛的协议和技术，为测试提供特殊的解决方案。企业通过LoadRunner能最大限度地缩短测试时间，优化性能并加速应用系统的发布周期。
LoadRunner提供了3大主要功能模块：Virtual User Generator（用于录制性能测试脚本），LoadRunner Controller（用于创建、运行和监控场景），LoadRunner Analysis（用于分析性能测试结果）既可以作为独立的工具完成各自的功能，又可以作为LoadRunner的一部分彼此衔接，与其他模块共同完成软件性能的整体测试。
详见：《性能测试入门——LoadRunner使用初探 （性能测试入门–LoadRunner使用初探 - A5创业网 ）》
LoadRunner官网：saas.hpe.com/zh-cn/soft
2. Apache JMeter
JMeter作为一款广为流传的开源压测产品，最初被设计用于Web应用测试，如今JMeter可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等，还能对服务器、网络或对象模拟巨大的负载，通过不同压力类别测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
JMeter的特点包括对HTTP、FTP服务器、数据库进行压力/性能测试；完全的可移植性；完全 Swing和轻量组件支持包；完全多线程；缓存和离线分析/回放测试结果；可链接的取样器；具有提供动态输入到测试的功能；支持脚本编程的取样器等。在设计阶段，JMeter能够充当HTTP PROXY（代理）来记录浏览器的HTTP请求，也可以记录Apache等WebServer的log文件来重现HTTP流量，并在测试运行时以此为依据设置重复次数和并发度（线程数）来进行压测。
参考文章：《云智慧压测实战分享之JMeter工具使用初探（云智慧压测实战分享之JMeter工具使用初探 - CloudwiseAPM - SegmentFault ）》
官网链接：Apache JMeter - Apache JMeter™
3. 阿里云PTS
阿里云性能测试（Performance Testing）是一个SaaS性能测试平台，具有强大的分布式压测能力，可模拟海量用户真实的业务场景，让应用性能问题无所遁形。PTS平台特色包括提供压测机，无需安装软件；脚本场景监控简单化，省时、省力；分布式并发压测，施压能力无上限；快速大规模集群扩容、支持几十万用户及百万级TPS性能压测；80%以上用户基本不需要花费额外的成本。
二、全链路压测技术
什么是全链路压测：从数据进入系统，经过一系列业务操作，到数据完成闭环，这一系列的业务操作及数据流转的过程，就构成了一个业务链路。而对这些链路进行压测，也就是全链路压测。
一、什么样的公司需要全链路压测？
既然全链路压测功能这么强大，那如何确定自己的公司是否需要做全链路压测呢？如果遇到以下问题之一，就可以考虑引入全链路压测：
(1) 压力测试一直在做，但是每到大促活动，各种问题依然频繁发生；
(2) 需求正常测试通过，上线后又出现各种各样的系统故障 ；
(3) 无法准确评估需要的机器资源，生产环境水位很低。
二、全链路压测的价值
1、 保障重大活动期间系统高性能、高可用、高稳定，避免公司业务和声誉因技术问题遭受重大损失。
2、精准的容量评估帮助公司用最低的成本满足业务的性能要求。
3、端到端的全链路压测巡检，第一时间发现故障并快速定位问题。
三、如何确定业务核心链路
一般有符合以下三种情况的，可以考虑确定为核心链路：
(1) 链路出现问题会对企业业务造成重大影响的链路，比如对业务造成损害、品牌损害等。
(2) 链路出现问题会对用户（如消费者）造成重大影响的链路，比如电商购物APP。
(3) 跟公司阶段考核（如KPI）挂钩的业务链路，比如订单团队肯定要保障订单链路的稳定。
四、全链路压测三大核心技术
1、全链路流量染色(流量隔离)
2、全链路数据隔离
3、全链路风险熔断
全链路流量染色，对压测的服务请求打上标识，在订单系统中提取压测标识，确保完整的程序上下文都持有该标识。
1、压测标记
压测标记就是最常见的压测流量染色的方式。一般会在服务请求的头信息中增加一个 Key：Value 的字段作为标记。
2、压测标记透传
目前公司内各个基础组件、存储组件，以及 RPC 框架都已经支持了压测标记的透传。下游服务可以根据压测标记完成对压测流量的处理。
3、压测开关
为了解决线上压测安全问题，我们还引入了压测开关组件。当线上出现压测问题，关闭压测开关，也能立即阻断压测流量。
因此我们要对服务进行改造：
在压测之前，需要对服务进行压测验证。对于不满足压测要求 (即压测数据隔离) 的服务，需要进行压测改造。
全链路数据隔离，主要是通过对压测流量进行染色，让线上服务能识别哪些是压测流量，哪些是正常业务流量，然后对压测流量进行特殊处理，以达到数据隔离的目的。
如：Mysql在持久化层根据压测标识进行路由访问压测数据表。数据隔离的手段有多种，如影子库、影子表
全链路风险熔断，也就是风险熔断机制，不管怎样做业务，可能都会对最终的生产业务造成一定的影响，真正出现问题的时候可能需要有快速熔断机制。一旦真的发现生产环境的线上压测对我们的业务造成了影响，我们需要通过一些规则或者其他的指标来自动触发风险熔断。如：自定义监控指标及阈值，到达阈值后，也会自动停止压测。例如 CPU、Memory、 上游稳定性、错误日志，以及其他自定义指标。
另：服务 Mock
对于调用链中不能压测的服务 (敏感服务)，或者第三方服务，为了压测请求的完整性，就需要对这些服务进行 Mock。业界通用的 Mock 方案有：
1、修改业务代码，修改服务调用为空转代码。优点：实现成本低。缺点：返回值固定，代码 & 业务入侵高，推动困难。如要 Mock 位置比较靠下游，超出部门覆盖业务范围，推动就非常麻烦。
2、通用 Mock 服务。通用 MockServer，会根据不同用户配置不同 Mock 规则，执行对应的响应延时，并返回对应响应数据。优点：无代码入侵，业务方无感知。缺点：实现成本高。
五、全链路压测架构
六、全链路压测流程
七、全链路压测模型
针对生产集群的全链路压测，需要涉及的压测模型较多，一般有如下几种：
①.梯度加压模型：主要为了探测集群模式下系统的最大吞吐量（也避免压垮服务，造成事故）；
②.固定并发模型：验证系统长期处于负载下的稳定性；
③.脉冲并发模型：探测系统的健壮性、验证限流熔断等服务保护措施的正确性&可用性；
④.超卖验证模型：对电商业务来说，主要针对一些限时抢购&秒杀的场景；一般这种场景，会涉及到分布式锁、
缓存、数据一致性等技术点；玩不好的话，容易造成客诉、资损、甚至服务异常宕机！
调用链监控是指在分布式系统中，记录和展示请求在多个微服务组件之间的调用过程和耗时情况的技术。
通过调用链监控，我们可以追踪请求在整个系统中的路径，并且识别出潜在的性能问题。
上图信息：
client send
客户端发送: 内容中心向用户中心发送请求的瞬间
server receive
服务端接收请求 : 用户中心接收到请求的瞬间
server send
服务端发送响应 : 用户中心响应请求的瞬间
client receive
客户端接收响应：内容中心接收请求的瞬间
在client send 瞬间向数据库记录 id为1的记录
service recive 瞬间记录 id为2的记录
service send 瞬间记录 id为3的记录
client recive 瞬间记录 id为4的记录
调用正常
用户中心返回了 但是 内容中心没有接收到响应，可能是网络异常
说明 users/1没有成功返回，api报异常了
说明请求发出去用户中心没有收到，可能请求瞬间网络有问题
t2 - t1 : 调用的网络耗时
t3 - t2 : users/1 api的耗时
t4 - t3 : 响应的网络耗时
t4 - t1 : 总耗时
掌握了原理我们使用不同的监控工具都会很容易上手！
开源的分布式追踪系统，它可以帮助我们监控跨越多个微服务的请求路径和性能。Zipkin提供了强大的UI和API，可以方便地查询和可视化调用链信息。
开源的分布式追踪系统，它支持多种语言和框架，并且提供了灵活的插件机制。Skywalking可以帮助我们追踪请求路径和性能，同时还支持告警和自定义指标。
四、性能调优技术
性能调优常规手段有：
空间换时间：内存、缓存就是典型的空间换时间的例子。利用内存缓存从磁盘上取出的数据，CPU请求数据直接从内存中获取，从而获取比从磁盘读取数据更高的效率。
时间换空间：当空间成为瓶颈时，切分数据分批次处理，用更少的空间完成任务处理。上传大附件时经常用这种方式。
分而治之：把任务切分，分开执行，也方便并行执行来提高效率。
异步处理：业务链路上有任务时间消耗较长，可以拆分业务，减少阻塞影响。常见的异步处理机制有
MQ（消息队列），目前在互联网应用中大量使用。
并行：多个进程或者线程同时处理业务，缩短业务处理时间，比如我们在银行办理业务时，如果排队人数较多时，银行会加开柜台。
离用户更近一点：比如CDN技术，把用户请求的静态资源放在离用户更近的地方。
一切可扩展：业务模块化、服务化（同时无状态化）、良好的水平扩展能力。
分布式架构的运用给性能带来了革命性的提升，业务流程的调整也会显著提升系统性能，单系统的调优能够压榨出更高的处理能力。
单机性能分析调优可从从以下四部分入手：
性能分析方法
基于单机的性能分析与调优
基于业务流程优化的性能分析调优
基于结构（分布式、业务拆分）的性能分析与调优
性能分析方法
性能分析是一个大课题，不同的架构、不同的应用场景、不同的程序语言分析的方法若有差异，抽象一下大致分为两类。
(1) 自底向上：通过监控硬件及操作系统的指标（CPU、内存、磁盘、网络等硬件资源的性能指标）来分析性能问题（配置、程序等问题）。因为用户请求最终是由计算机硬件设备来完成的，做事的是CPU。
(2) 自顶向下：通过生成负载来观察被测试的系统性能，比如响应时间、吞吐量；然后从请求的起点由外及里一层一层的分析，从而找到性能问题所在。
不管是自上而下还是自下而上，关键点就是生成负载、监控性能指标。好一点的方式是先用自顶向下的方式解决掉明显的性能问题，再结合自底向上的方式分析更深层次的问题。
单机的性能分析与调优
常见的J2EE应用架构，一般分为Web层（请求接入、负载均衡、页面渲染等）、应用层（业务逻辑实现）、持久化层（数据记录）。
下面列出了性能测试时我们需要关注的指标。
Client：客户浏览器，比如IE、Chrome等访问Web页面。
Load Machine：是生成负载的机器，即我们的压测机器用来模拟用户负载。
Web Server：提供Web服务的服务器，即我们访问的Web页面由此服务器提供服务；一般都部署在Nginx、Apache等中间件上。
Middleware：中间件，比如Tomcat、Jboss、WebLogic等。
OS：操作系统，Windows或者Linux。
System Resource：系统资源，比如CPU、内存、磁盘、网络等。
App Server：应用服务，实现业务逻辑，比如生成订单，生成统计报表。
DB：数据库服务器，比如Oracle、Mysql、SqlServer等。
RT：响应时间，一笔业务的完成时间。
TPS：每秒完成的事物数。
CPU：CPU的性能指标，比如CPU利用率、CPU负载。
Mem：内存性能指标，比如可用物理内存、虚拟内存使用率。
Disks：Disk性能指标， 比如Disk Time、IO等待。
Network：网络指标，如带宽使用率，任务队列长度。
TCP Connections：指TCP连接数，可以用netstat命令统计得到。
Thread Pool：中间件建立的线程池，监控线程状态。
JVM：JVM性能指标，比如GC情况，Heap使用情况。
Load Average：CPU负载队列长度。
DB Connections：中间件与数据库之间建立的连接数及连接状态。
DB Time：消耗在数据库操作上的CPU时间。
OP SQL：按内存占用由多到少排序SQL，按CPU占用由多到少排序SQL。PGA、SGA：PGA、SGA内存使用情况。
性能分析过程：
上表列举了一种典型的分析思路，可以看到性能测试结果分析是一个考验综合知识的活动，涉及了多方面的知识，包括但不限于下面7部分：
硬件知识（CPU、RAM、Disk、Net等）。
系统知识（OS----Linux、Windows）。
中间件知识（JVM、Tomcat、Jboss、WebLogic、WebSphere等）。
数据库知识（Mysql、Sql Server、Oracle、DB2、Sysbase等）。
网络知识（比如截包分析）。
程序知识，比如Java程序，如何让程序更高效。
架构知识，比如SSH架构。
大型系统的复杂度已经不是一个人力所能及的事情。上面提到的7个部分就可以是多个岗位（运维、程序员、架构师、DBA等），每个岗位又配置专业人员。性能分析时从他们那里获取性能指标数据，这些信息汇总后用来判断是否有性能问题。
对于性能测试工程师来说首先要做到的事情是要知道监控哪些指标？这些指标反应什么问题？什么时候去关注这些监控信息？在性能测试执行与分析时你就是总设计师，负责协调这些事项。
程序优化
程序调优是治本的手段，当前性能测试往往都是在SIT测试完成后进行的，性能问题暴露得太晚，这个时候去修改代码，风险较大。所以性能测试往往要提前规划，先架构后程序（先整体后个体）。
（1） 系统框架选择
SSH架构是当下最流行的MVC模型。SSH架构提供了明晰的层次结构，各层协同完成业务实现，简化了程序设计过程，加快了程序交付进程。但是对大型的业务系统，特别是大数据量的分析计算过程，可以把数据处理换成在数据库中进行处理，减少网络传输，性能也会提升，所以应该不同的应用场景选择更合适的处理方式。
（2） 程序优化
低效代码优化，排除架构问题，纯粹是程序逻辑及算法抵消，比如逻辑混乱、调用继承不合理、内存泄漏等。常见的解决方法如下：
表单压缩，减少网络的传输量
局部刷新，减少向服务器的请求
仅取所需，只向服务器请求必要的内容
逻辑清晰，方便维护、方便分析问题；不做错误及多余的调用，资源请求后能够释放
谨慎继承，开发过程对系统架构熟悉，合理调用，减少大对象产生的可能
程序算法优化，提高查询程序效率
批处理，对于大数据最好做成分批处理
延迟加载，对于大对象的展示可以采用延迟加载，比如分页，用到分页时再去请求
防止内存泄漏
减少大对象的引用
防止争用死锁
索引：编写合理的SQL，尽量利用索引
内存分配，合理分配数据库内存，比如PGA与SGA的设置
并行，使用多进程或进程来处理任务
异步，比如用MQ来解耦系统之间的依赖关系，减少阻塞
使用好的设计模式来优化程序，比如用回调来减少阻塞，使用监听器来阻塞依赖
选择合适的IO模式，比如NIO、AIO等
（3） 配置优化
JVM配置优化：合理的分配堆与非堆的内存，配置适合的内存回收算法，提高系统服务能力
连接池：数据库连接池可以节省建立连接与关闭连接的资源消耗
线程池：通过缓存线程的状态来减少新建线程与关闭线程的开销，一般是在中间件中进行配置，比如在Tomcat的server.xml文件中进行配置
缓存机制：通过数据的缓存来减少磁盘的读写压力，缩小存储与CPU的效率差
（4） 数据库连接池优化
数据库连接池存在的意义是让连接复用，通过建立一个数据库连接池（缓冲区）以及一套连接使用、分配、管理策略，使用的该连接池中的连接可以得到高效、安全的复用，避免了数据库连接频繁建立、关闭的开销。
连接池的主要关注的问题：
连接池的配置参数。
连接池配置多少连接合适
监控连接池
（5） 线程优化
线程池优化，线程池是为了减少创建新线程和销毁线程的系统资源消耗
CPU处理能力
内存容量
系统线程数限制
（6）DB优化
通常使用数据库有3个要求，性能好、数据一致性有保障、数据安全可靠；数据库优化前提也是这3个要求。
优化物理结构，数据库逻辑设计与物理设计要科学高效，比如分区、索引建立、字段类型及长短、冗余设计等
共享SQL、绑定变量、降低高水位
查询器优化，特殊情况调整执行计划。指定的执行计划加快查找速度。比如连接查询时指定驱动表，减少表的扫描次数
单条SQL优化，对单条SQL进行优化分析，比如查询条件选择索引列
并行SQL，对数据量巨大的表的数据遍历，用多个线程分块处理任务。
减少资源争用（锁、闩锁、缓存），可以提高IO效率减小响应时间从而提高吞吐量来缓解争用，比如用缓存；可以物理拆分把热点数据分布在不同表空间
（7） 优化内存、减少物理IO访问
（8） 优化IO，进行条带化、读写分离、减少热点等
注意：单系统性能分析的思路是通过现象结合监控锁定性能问题（程序、配置、IO等）单系统性能调优的思路是减少资源占用，减少请求
业务流程优化
准确地说就是业务架构调整，业务架构是整个系统好坏成败的关键，对此处做调整就是推翻先前的设计，风险比较大。这点对于架构师的要求很明确。现实往往是残酷的，反过来想一下，正是因为这种矛盾的存在才导致了性能测试以及性能调优的存在。
结构优化
业务的增长导致性能问题推动着架构的发展，从单机到集群再到分布式结构。
联系客服
