其实以往的产品初次上线前的过程里，对于性能测试的需求是被惯性弱化的，因为我们用控制流量，白名单机制来等方式一点点消磨取代这方面测试的考量，再加上市场上高性能工具（中间件，负载均衡，消息处理机制的层出不穷）的叠加使用。可能不在考虑，至少不在上线初期考虑这方面内容。
风险显而易见的就是你真到了哪天用户量上来了，要再想优化性能，就变成了直接优化系统架构，因为系统到那个时候冗余到什么程度和地步，无法预测。这个代价是自己“惯性造成的”，自己挖的自己埋吧。
业务背景：
知识：
可能影响ART的指标有至少以下这些：
业务方面：简单来说就以下两个
2.业务复杂度提高，这个好理解，业务复杂了以前三步能搞定的事儿，需要六步搞定，肯定也会受到影响。
系统方面：这个比较多，性能测试中真正去调优的过程，恰恰是以下方式的倒叙。
1.系统资源，硬件资源过小，不足以支撑现有用户量，或者递增，激增用户及业务量。
2.系统资源配置，中间件配置，数据库配置，应用server配置，配置项可能包含的点：Linux系统参数，如文件句柄，端口回收机制。中间件连接数，数据库连接数，应用server框架及其部署方式，熔断机制，流控机制，应用日志级别等。
3.代码处理方式，代码逻辑方式。
4.数据库效率，SQL效率。
5.测试时的加压方式，性能测试脚本合理性，参数合理性，测试数据分布的合理性。
ART分析：
分析之前：
要知道以下几点非常重要：
1.性能测试是必须以性能测试目标（测试指标）为导向的测试（当然功能测试也应该是，但是好像功能测试最后可以妥协），否则没有任何意义。
2.有了第一点的意识，就必须知道你的目标在哪，ART值的多少就是你的其中一个很重要的测试指标。
3.指标一定是测试开始前分析出来的，数据量化出来的，如果你是脑洞的，你的测试就是最大的漏洞，测试结果对系统的影响也很有可能是破坏性的。
性能测试有多折磨人，显而易见了，因为就一个ART的结果你就要通盘考虑以上所有的，何况还有更恐怖的TPS。当然价值与成就感也不言而喻了。需要强调的是这种成就感和价值，这对于研发和测试起到的作用是同等的，且积极的。
分析定位：
要想准确定位ART是多少，那我们怎么入手，怎么分析呢，因为我们的系统有N个系统模块，还不算银行系统有多少次交互，和有多少个系统。
那么方法论来了：拆分，细化，排序外加木桶理论。逐一来讲一下：
拆分
无论你有多少个系统，多少个模块，我们都要在开始测试前拆分出来，认清楚你的交易路径经过了多少个系统，本次测试一笔交易要经过网关系统，账户模块，支付模块，及银行网关系统。
细化：
清楚了交易路径，我们就要进行细化交易，细化到最简单的交易路径，比如我们的目的只是为了测试自己的充值逻辑是否有瓶颈，事实是测试过程中，充值，提现，都在基准负载测试中无法达标（我们定的目标是500ms-800ms以内），
排序：
木桶理论的运用：短板决定最终导向。
假设节点1网关，节点2账户，节点3支付，节点4银行系统。
优先级1：(t9、t10)、(t7、t12)、(t5、t14)、(t3、t16)
优先级2：(t8、t11)、(t6、t13)、(t4、t15)、(t2、t17)
优先级3：(t1、t18)
性能压力工具本身产生的响应问题，非常少。但是也并不是不存在，所以我们放到最后来检查。可以看出我们主要关心(t7、t12)就可以了。
结果：
业界对ART的共识与误区：
一个近乎这些年遗忘的原则258原则，更正一下这个认识吧，如果你知道的是伪道理（以下背景知识是搜索来的，不过受用）：
4秒是业务可以接受的上限，因为到了4秒的时候，客户流失率明显增加了；
10秒是完全不可接受的，因为已经导致企业的经济已经入不敷出了。
总的来说这东西是一个很老旧的并且不受用在其他系统的里一个破原则，居然被使用了这么多年，还差点儿搞成了课本，殊不知因地制宜，因人而异，因系统不同而不同的道理。
总结：
2.量化性能目标（包括分解性能目标、量化各部分性能目标）；
3.确定系统功能和交易路径；
4.满足性能目标
最后想说的是，架构时且行且思考，实现时且行且思考，测试时且行且耐心，细致，思考。