当一个应用系统需求被提出，就需要确定性能需求，即：需要给多少人同时来使用，就是多少人可以同时在线；平均响应时间有多长；每秒通过的交易（transaction）个数有多少；需要的网络带宽有多大等等。
系统设计，就需要遵循性能需求，进行性能架构设计。比如，是否使用集群、双机热备、N+1等模式。当然，随着两地三中心的模式，也需要充分考虑到性能需求和性能架构设计的要求。
决定性能的要素，包括了：性能需求、性能架构与设计、代码实现几个部分。
性能架构，很多系统都是分成不同的层，以及不同的业务组件来实现具体的应用，一般而言包括了交易处理层、业务组件层、数据库服务层三个大的部分。当系统的性能出现问题，我们就需要知道，
上图是一个比较简单的架构。当系统的性能达不到要求，我们就要分析问题出在哪一层上。分析在哪一层，最简单的方法，就是分析业务流量路径图：
根据业务流量的路径，对每个层进行性能数据监控，得到每个模块被调用的次数，以及响应时间的数据，从而分析获得性能瓶颈。
随着业务的复杂度提升，系统架构也日益复杂，出现了微服务或者很多跨系统的业务场景：
如上图，就需要对外系统或者调用外系统的接口服务进行监控，获得监控数据。
获得监控数据之后，就需要对可疑的数据进行分析。什么是可疑的数据？就是按照正常的情况，不应该出现的性能曲线，比如数据库sql语句执行突然缓慢（随着数据量的增加），交易响应时间突然变长，但是cpu却没有大幅度增加等等。
如上图，是TPS随时间变化的趋势图。随着时间的变化，客户端发起的压力逐步上升，当上升到一等幅度之后，突然开始震动和下降，出现了性能瓶颈。
最后，我们来说一下加压。加压就是模仿客户端，生成持续的交易请求，向系统加压。
如上图，我们采用PerformanceRunne性能测试工具r的架构图，来展示如何产生压力：
PR的节点管理器，负责管理多个虚拟机或者实体机，在实体机上会通过多进程和多线程来模拟用户请求。
模拟用户请求的方式是采用测试脚本来模拟发起报文和接收响应报文：
简单的协议，比如http、https、socket等，可以通过录制来获得测试脚本，对于复杂的协议或者通讯中间件，比如MQ、tuxedo、cics等，就无法通过录制来获得，就需要手工编写测试脚本。
脚本编写完成，我们需要对脚本进行参数化，以实现加压的时候，产生压力的数据是不同的，从而模拟更真实的应用场景：
针对具体的统计口径和业务相关性，例如：当我们通过浏览器页面登录到一个系统，一般而言，登录是一个服务，登录完成之后，会请求用户桌面上的各个数据，或者仪表盘信息，是另外的请求。在产生压力和统计的时候，我们需要把这两个或者多个，组合在一起，变成一个交易（transaction），tps的数据也是统计交易的数据，这样避免了编写的测试脚本和真实的压力效果不同，如下图：
性能测试脚本创建完成，我们就可以根据具体的业务场景来加压了。一个业务场景，可以对应一个或者多个测试脚本。
压力产生策略。我们可以选择逐步梯度增加并发个数（VU虚拟用户），来逐步产生压力，发现加压到某个压力的时候，会出现性能瓶颈。
性能测试工具，对各个节点进行监控，产生性能监控数据：
推荐阅读：
sales@spasvo.com
