背景：
其实以往的产品初次上线前的过程里，对于性能测试的需求是被惯性弱化的，因为我们用控制流量，白名单机制来等方式一点点消磨取代这方面测试的考量，再加上市场上高性能工具（中间件，负载均衡，消息处理机制的层出不穷）的叠加使用。可能不在考虑，至少不在上线初期考虑这方面内容。
风险显而易见的就是你真到了哪天用户量上来了，要再想优化性能，就变成了直接优化系统架构，因为系统到那个时候冗余到什么程度和地步，无法预测。这个代价是自己“惯性造成的”，自己挖的自己埋吧。
好在，本次受制于银行给我们提了刚性需求，性能测试必须完成，并输出相应报告，才有了本次的分析与分享，调优和测试人员体会颇深，输出出来，与君共勉吧。估计看完了下面的东东，更不想性能测试了。。。
业务背景：
很简单，项目第一次在银行生产环境上线，对核心交易进行压测，找出核心交易是否有瓶颈，对于整个专业的性能测试过程来讲，要求算简单的了。本次分享给大家的，也是关于一个指标达标的定位，优化的过程，即ART响应时间。
知识：
ART是个啥：“平均事务响应时间”显示的是测试场景运行期间的每一次事务执行所用的时间，通过它可以分析场景运行期间应用系统的性能走向。例如随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着时间的变化，整体性能将会有下降的趋势。
可能影响ART的指标有至少以下这些：
业务方面：简单来说就以下两个：
1.用户量，用户量多了不受影响，那这个系统真的很牛X，当然我说的是大批量用户激增，或者日积月累大批量用户引入。正常系统都会被其影响响应时间。
2.业务复杂度提高，这个好理解，业务复杂了以前三步能搞定的事儿，需要六步搞定，肯定也会受到影响。
系统方面：这个比较多，性能测试中真正去调优的过程，恰恰是以下方式的倒叙。
1.系统资源，硬件资源过小，不足以支撑现有用户量，或者递增，激增用户及业务量。
2.系统资源配置，中间件配置，数据库配置，应用server配置，配置项可能包含的点：Linux系统参数，如文件句柄，端口回收机制。中间件连接数，数据库连接数，应用server框架及其部署方式，熔断机制，流控机制，应用日志级别等。
3.代码处理方式，代码逻辑方式。
4.数据库效率，SQL效率。
5.测试时的加压方式，性能测试脚本合理性，参数合理性，测试数据分布的合理性。
ART 分析：
分析之前，经常有人问你，你的交易响应时间是多少，TPS能到多少（这东西不在这儿说了），我们的系统性能差，应该如何分析响应时间呢。响应时间的长短如何定义呢。
要知道以下几点非常重要：
1.性能测试是必须以性能测试目标（测试指标）为导向的测试（当然功能测试也应该是，但是好像功能测试最后可以妥协），否则没有任何意义。
2.有了第一点的意识，就必须知道你的目标在哪，ART值的多少就是你的其中一个很重要的测试指标。
3.指标一定是测试开始前分析出来的，数据量化出来的，如果你是脑洞的，你的测试就是最大的漏洞，测试结果对系统的影响也很有可能是破坏性的。
性能测试有多折磨人，显而易见了，因为就一个ART的结果你就要通盘考虑以上所有的，何况还有更恐怖的TPS。当然价值与成就感也不言而喻了。需要强调的是这种成就感和价值，这对于研发和测试起到的作用是同等的，且积极的。
分析定位：
要想准确定位ART是多少，那我们怎么入手，怎么分析呢，因为我们的系统有N个系统模块，还不算银行系统有多少次交互，和有多少个系统。
那么方法论来了：拆分，细化，排序外加木桶理论。逐一来讲一下：
· 拆分
无论你有多少个系统，多少个模块，我们都要在开始测试前拆分出来，认清楚你的交易路径经过了多少个系统，本次测试一笔交易要经过网关系统，账户模块，支付模块，及银行网关系统。
· 细化
清楚了交易路径，我们就要进行细化交易，细化到最简单的交易路径，比如我们的目的只是为了测试自己的充值逻辑是否有瓶颈，事实是测试过程中，充值，提现，都在基准负载测试中无法达标（我们定的目标是500ms-800ms以内），以充值交易为例，剔除其他任何指标的影响，只是支付模块进行了充值逻辑的处理，那么我们主要关注的就应该是这个模块。
· 排序
有了交易路径，有了主要测试核心目标模块（支付模块），我们要定位充值交易的响应时间耗时，都合理的在哪里消耗掉了，如下图（图是网上找来的，实在懒得画了，也能说明道理）：
木桶理论的运用：短板决定最终导向。
假设节点1 网关，节点2 账户，节点3 支付，节点4银行系统。
在压力工具中，看到的响应时间，把后面一系列（t1-t18）都包含在内了。所以只拿压力工具中的响应时间来讨论是不可能有结论的，所以拆分响应时间才如此重要。
对一个没有全局跟踪id的系统来说，这个时间的查找确实非常费劲，只能通过业务中带的某个ID来一个节点一个节点找下去。其实能找下去就已经是很好的了。而对有些系统来说，查响应时间简直就是噩梦般的操作。因为有些日志打印的只有两个字可以形容：恶心！
所以响应时间的长短，不要再只看压力工具上告诉你的了，拆分下去我们就想知道节点3耗时了多少，ok其他全都干掉，当然不是全都干掉，该mock的mock，比如银行系统（这货耗时多久先不管，先给他50ms让他刷个存在感）；该排除的排除，因为其余模块分析过后发现没有任何影响，这里不做赘述了。
在大部分情况下，我们都不用关心t1/t2/t4/t6/t8/t11/t13/t15/t17/t18，也就是说除了各业务节点上所消耗的时间外，其他地方出现响应时间的问题的可能性比较小。所以在分析响应时间的时候，我们必须列出查找的优先级，那就是：
优先级1：(t9、t10)、(t7、t12)、(t5、t14)、(t3、t16)
优先级2：(t8、t11)、(t6、t13)、(t4、t15)、(t2、t17)
优先级3：(t1、t18)
性能压力工具本身产生的响应问题，非常少。但是也并不是不存在，所以我们放到最后来检查。可以看出我们主要关心(t7、t12)就可以了。
结果：
最终我们也确实发现了，(t7、t12) 的消耗过程中确实出现了问题，当然整个过程中还排查了sql的使用，增加了该建立的索引，再此基础上仍然没有解决ART缓慢问题。所以又进行了恐怖的更磨人的工作，逐个方法加响应时间，看看具体哪个逻辑出了问题，看看如下截图，就知其中多痛苦：
最终发现是发向银行报文的解析方式上耗时很多，优化了解析报文方式和函数：提高ART效率3倍。
业界对ART的共识与误区：
一个近乎这些年遗忘的原则258原则，更正一下这个认识吧，如果你知道的是伪道理（以下背景知识是搜索来的，不过受用）：
显然，现在大部分人都不再把258原则当成一回事了。但可悲的是，性能测试人员的第一课就被大部分人教成了响应时间要遵循258原则；就像性能行业中经常有人拿理发店模型来说并发一样可悲。
不能不说，性能测试这个行业发展了十几年（我从业的时间段），到现在为止还有些知识从来未被更新（特别是在意识里）。
在这里，我完完整整的解释下258响应时间，希望能纠正一些视听：
首先，258响应时间是来源于80年代英国的一家媒体针对media做的调查，也就是提供音乐服务的。在这个调查中，2秒是90%以上的都认为是优质的服务。响应时间越长，满意的人当然就越少。而到了8秒的时候，差不多有50%的人都不满意了。我记得当时我看到的时候还有一个时间和人员流失率的对比图。在80年代，你可以想像，那时的服务是个什么标准，我只知道那时我还不记事。
但是那个报告影响了很多事情，以致在国内的性能领域至今还有人当成科普来教新入行的人。到了90年代，应该是1993年，美国的一家媒体做了另一个针对响应时间的调查，这次是针对零售业，也就是亚马逊、ebay之类的电商服务。这次得出的结论是：
1秒是较好的的响应时间，记住是较好而不是最理想；
0.1秒是最理想的响应时间，因为0.1秒人是无感知的，而1秒会让人感觉到停顿，但是也是可接受的；
4秒是业务可以接受的上限，因为到了4秒的时候，客户流失率明显增加了；
10秒是完全不可接受的，因为已经导致企业的经济已经入不敷出了。
总的来说这东西是一个很老旧的并且不受用在其他系统的里一个破原则，居然被使用了这么多年，还差点儿搞成了课本，殊不知因地制宜，因人而异，因系统不同而不同的道理。
所以请大家在以后的工作中不要再拿响应时间要遵循258原则来说事，因为它实在是离我们太遥远了。
总结：
响应时间ART定位准确请尊从以下步骤：
1.收集性能目标；（也就是调查用户对响应时间的满意值）
2.量化性能目标（包括分解性能目标、量化各部分性能目标）；
3.确定系统功能和交易路径；
4.满足性能目标。
在经过了这些步骤之后，才能让我们明确响应时间这个指标。别看最后一步字很少，却是巨大的工作量之所在。但是第二点，虽然工作量上没有最后一点多，但是最烧脑的可能就是第二点。这需要，性能测试工程师，架构师，项目经理，需求负责人这些要职的人员进行配合并给出准确的数据，在有性能测试工程师进行加工优化。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
