老徐组织个提高性能测试水平的在线联想活动，欢迎大家参与：）

cloudxu

<P>老徐组织个提高性能测试水平的在线联想活动，欢迎大家参与：） <BR>&nbsp;<BR>这个在线提高水平活动的方法是这样的：）</P>
<P>（1）老徐首先提出一个性能测试中的概念，例如什么是性能测试？</P>
<P>（2）老徐会对这个“性能测试”进行联想，例如，由“性能测试”联想到“响应时间”，并对“响应时间”进行一个简单（或者详细）的描述</P>
<P>（3）任何人可以接着对“响应时间”进行联想，例如由“响应时间”联想到“响应时间与负载之间的关系”，并对“响应时间与负载之间的关系”进行一个简单（或者详细）的描述</P>
<P>（4）任何人可以一直接着联想下去......</P>
<P>我想，这个活动对我们每个人，懂性能测试的、熟悉性能测试的、了解性能测试的、不懂性能测试的，都是一个能丰富性能测试知识、提高对性能测试认识、自我审查性能测试技能水平的好机会：） </P>
<P>&nbsp;</P>
<P>老徐第一个开始：）</P>
<P>“响应时间”</P>
<P>“响应时间”是可以判断一个被测应用系统是否存在性能瓶颈的最直观的要素</P>
<P>例如，在执行完性能测试后，发现某个交易的“平均响应时间”为8秒，超过了预先确定下来的性能指标“该交易的性能指标为平均响应时间要小于等于3秒”。此时，就可以认为被测应用系统存在性能瓶颈了，要利用一定的手段去探查被测应用系统中哪个地方引起了系统的处理效率低以及低的原因了。</P>
<P>“响应时间”一般包括“最大响应时间”和“平均响应时间”。</P>
<P>“响应时间”包括网络上的传输时间，WEB服务器上处理时间、APP服务器上的处理时间、DB服务器上的处理时间</P>
<P>“响应时间”不包括IE浏览器上的内容显示时间</P>
<P>欢迎大家接下去.......：）</P>
<P><BR>感觉没尽兴 ：）</P>
<P>老徐再接一个</P>
<P>针对“响应时间”，我可以联想到“负载”</P>
<P>因为“响应时间”与“负载”存在一定的关系</P>
<P>“负载”分为“在线用户负载”和“并发用户负载”</P>
<P>例如，某天上午10点时，同时的在线用户一共有1000个人，我们可以称此时的在线用户负载为1000</P>
<P>随着“负载”的增加，响应时间也会逐渐的增加</P>
<P>当到达某个负载级别之后，响应时间将会急剧的增加</P>
<P>如果是一个性能比较好的应用系统，当负载从0逐渐增加时，例如，1个、5个、10个、15个、20个、25个.....</P>
<P>在出示增加阶段，响应时间应该增加的不明显，</P>
<P>当到达例如500个的时候，可能由于某种资源到达了瓶颈、或者程序的某个地方到达了瓶颈，从此之后，随着负载的继续增加，响应时间将急剧上升......</P>

[ 本帖最后由 cloudxu 于 2007-4-29 11:05 编辑 ]

tacy_lee

huangjien的说法我比较同意，在假定的业务场景下，系统满足sla规定的tps,response time,resource util

huangjien

个人感觉最重要的指标应该是TPS，这是衡量系统能力的指标，也是性能测试想得到结果。响应时间和吞吐量是侧面描述指标。 也就是说，我们进行性能测试，就是想知道：在指定的响应时间内，系统的TPS是多少；如果可能，我们应该进一步知道：扩展TPS的方法是什么。
但是，通常没有这么理想，性能测试往往都是在找系统的瓶颈在那儿。实践中，只能给出一个报告，说明系统达标了，达标的依据就是--响应时间。

wssgily

帮你顶一下吧