ACT做压力测试

近期做了几天的测试工作。将获得的一些经验整理成文，可分以下两点：

 

一、充足的准备――测试工作的前提环节

测试准备工作直接影响到测试工作的成败，其大致分如下几点：

１、硬件环境的准备工作

1)        测试客户端和被测服务器端硬件配置的合理搭配，二者配置差距不宜过大，因此应尽量使用高配置的测试客户端；

2)        使用稳定的通讯网络。由于互联网的不可预知性，不同时间的测试，所获得的数据也不一致，若无资深的技术支持，建议使用局域网络进行测试工作，且该线路在测试同时尽量不要有其它的无关数据通信；

3)        制定规范的测试流程和测试结果报表，如此方能按预期安排好的分析方法进行数据分析。如果条件许可，最好确定多条测试流程以备用。

２、确定要测试的目的

测试可大致分为两种：压力测试和功能测试，其中功能测试下又分有多种性能测试。只有先确定目的才能制定正确有效的测试方法。

二、完备的分析方案――测试工作的核心环节

针对不同的实际测试操作环境，应确定适用的分析方案。测试软件可获得的数据虽多，但对测试目的有用的关键数据往往就是那几项。如在通过ＡＣＴ进行压力测试时，要获得产生最大ＲＰＳ值的最大连接数，关键性的数据项有：

１、总请求数：

测试运行期间发送的请求总数；

２、连接数：

 

　　测试运行发生时模拟浏览器与ＷＥＢ服务器发生的连接数；

 

３、每秒平均请求数（简称：ＲＰＳ）：

 

每秒发送的平均请求数，不包括多次发送的请求（例如，由于 Web 服务器要求身份验证）。该值根据每秒收集到的数据计算。服务器对客户端请求的响应时间越短，该数值越大；Web 应用程序通常会增大 RPS 值至某一特定值，在连接数超过了 Web 服务器可以处理的数量时，就会开始显示较低的 RPS 值。这样，就可以确定最佳每秒请求数对应的浏览器同时连接数。如果同时连接数超过了该最佳值，Web 站点每秒处理的请求数就会降低。

 

４、HTTP 错误数：

 

　　带有 400-499 和 500-599 范围内结果代码的所有响应的总计。在此顺便说明一下服务器ＨＴＴＰ响应代码所表示含义：２００～３９９通常表示正确的服务器响应；４００～４９９通常表示由于客户端请求的ＨＴＴＰ头部信息中发生错误导致服务器出错；５００～５９９通常表示服务器内部造成的错误，该类错误大多数由系统程序造成。

 

　　

通过这几天的摸索，找到一条压力测试中获取“最大ＲＰＳ值对应的最大连接数”时可供参考的方法：通过设置不同的连接数（具体数值应根据不同情况进行分析）进行多次测试，使用ＡＣＴ自动绘制的曲线图（将连接数设置为Ｘ轴，将ＲＰＳ设置为Ｙ轴）来找ＲＰＳ峰值所对应的连接数。

在这几天的测试中由于获取到的测试值不具备参考价值，导致测试没有成功，而原因一直没有找到。值得一提的是，在使用ＷＩＮ２００３企业版做为服务器时，服务器在过载情况下（即：设置的连接数远大于预期值，如５００、１０００）始终没有返回代码为４０３的拒绝服务代码；而使用ＷＩＮ２０００专业版时，服务器在过载情况下返回了大量代码为４０３的拒绝服务代码，如此亦可做为参考ＷＩＮ２０００服务器是否过载的依据。以上为几天摸索获得的小结，不一定正确，谨与大家参考与讨论，谢谢。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/asp_sunglow/archive/2005/12/06/545064.aspx

 

//********************************************

使用Application Center Test (ACT)来做压力测试

在我们完成了基于SPS2003的开发，实现了我们的具体应用以后，我们是不是就可以直接请用户来使用了呢？如果我这么做，那么有经验的开发人员一定会对此嗤之以鼻：居然连压力测试也不做！真是不想活了……

 

呵呵，是啊。开发环境往往只考虑功能，到了具体环境中，就需要考虑有大量的用户来访问的时候，很多功能会不会出错？性能会怎么样呢？……我们这里就简单看看，怎么来做压力测试。

 

相信作压力测试肯定有很多工具，而我们一般使用的，现在很多是Application Center Test (ACT)。这个东东是VS.NET中的一个组建，很简单，容易上手，而且支持脚本，也可以实现复杂的功能……

 

这里省略测试步骤，假设我们只是直接对一个网站做测试，例如Test.SendRequest("http://server/default.aspx")。现在怎样来分析结果呢？

 

下面是我刚学到的一些信息，和大家共享，希望对于有经验的朋友，起一个抛砖引玉的功能。

 

1. 首先，检查一下又没有错误，例如401用户没有验证的错误。如果有错误，那么结果肯定是不对的，也不用看了。

 

2. 分析Average requests per second，应该就是“每秒平均请求”。

 

我们可以多测试几次，使用1、2、5、10、50、100、200……的并发浏览器连接数目。然后，我们可以把几次结果放在一个图表中来分析。

 

一般情况下，随着并发浏览器连接数目的增加，Average requests per second的数目也会增加，但当到了某一个值以后，再增加就反而导致Average requests per second下降了。那么，这个值就差不多是服务器能支持的最大并发浏览器连接数目。

 

3. Average time to last byte

 

是发送请求以后，到收到服务器响应结束的时间。

 

显然，一般情况下，随着并发浏览器连接数目的增加，这个值是会随着变大的。一般情况下，分析这个值是不是合理，可以参考下面的标准：

 

0.1秒：      非常快了

1秒：          速度还是非常快的，基本不用考虑性能问题

3 – 4秒：    对于内部网络，可以接受的一个结果

5 – 8秒：    对于外部网络，可以接受的一个结果

10秒以上：   太慢了一些

 

4. Average time to first byte

 

一样，只不过是发送请求以后，到收到服务器响应开始的时间。

 

# re: 使用Application Center Test (ACT)来做压力测试

sps中的并发数是个让人混淆的东西, 他指的是"同一瞬间同时电击的浏览器数", 即便是这个时候有ie打开某sps网页，但只要不电击，仍然不应该被计入这个时候并发数。所以这个数字一般不会太大。即便如一个有30000人的大公司，一般也很难超过10.

所以，每秒平均请求一般没有必要到100，200。。。