用程序连接数，从而直接影响性能和可扩展件。这些问题将会在系统体系结构的所有级
别出现，包括网络层、web服务器、应用服务器以及数据库服务器。
快速瓶颈识别(RapN Bnnlcneck ldentify，RBI)9“是EmPirix公司提出的一种用于
快速识别系统性能瓶颈的方法，可以帮助质量保证专业人员快速地发现web应用程序性
能限制，并确定这些限制对最终用户体验的影响。RBI方法的开发历经数年．涵盖了所有
类型平台的测试，可显著缩短负载测试周期，同时允许进行更加彻底的测试。
使用RBI方法基于以下二条原则：
①所有web应用程序都具有瓶颈；
⑦每次只能发现其巾一个瓶颈；
②应该将重点放在哪里，则最可能出现瓶颈。
在确定具体的性能瓶颈时，R则将性能瓶颈的定位按照“自上而下”的方式进行分析，
即首先确定是由并发还是由吞叶量引发的性能限制，然后从网络、数据库、应用服务器和
代码本身4个环节确定系统性能具体的版颈。从简单到复杂的测试流程可以使得出现问
题时所有其他可能的原因均被排除，而着重于吞吐量测试。然后进行并发性测试，并使用
结构化流程测试方法，确保快速隔离瓶颈，从而提高效率并降低成本。
虽然配BI方法在性能瓶颈的定位过程中发挥了良好的作用，但只是依据吞吐量作为
系统瓶颈的关键内素，没有考虑全面的性能指标．同时也没省提供完整的性能测试过程和
性能缺陷分析方法，这正是需要改进的一个方面。
性能下降曲线实际k描述的是性能随用户数增长而出现下降趋势的曲线。而这里所
说的“性能”一般是指响应时间，但也可以指吞吐量等其他数据。图2—l展示了两条相对
基础的响应时间性能下降曲线，具体描绘了用户的访问时间与系统用户负载之间的对比
情况。
图2—1中的纵轴措述的是几秒钟内端到端的响应时间，横铀则表示访问系统的当前
用户总数。除此之外，图中还包含了数据表。随着更多的用户接入系统，图巾用户访问的
时间就象预料的情况那样增加或者减少。图中展示的数据表所生成的是最普遍的响应时
间性能曲线形状．95％以上的曲线图都会像该图一样。如果出现较大的偏差．主要原因可
以从以下几点考虑：
①用户群体模型不难确；
②编写的脚本不具有用户群体模型代表性
③测试的系统无法处理多用户；
④测试没有真正对系统产生压力。