在做性能测试之后需要知道些什么

发表于:2012-07-16来源:博客园作者:虫师点击数: 标签:性能测试
之前写过一篇《在做性能测试之前应该知道什么》有博文,自我感觉讲的不好,举了两个例子,和做性能测试之前需要知道的一些要点。离我的题目有差距。二则觉得讲的不全。其实,要做性能测试需要知道的东西太多了。岂是一篇博文都能说全的。在这里表示一下愧疚之

  之前写过一篇《在做性能测试之前应该知道什么》有博文,自我感觉讲的不好,举了两个例子,和做性能测试之前需要知道的一些要点。离我的题目有差距。二则觉得讲的不全。其实,要做性能测试需要知道的东西太多了。岂是一篇博文都能说全的。在这里表示一下愧疚之情。

  好多测试新手,在做完性能测试之后,不知如何对测试数据进行分析。在这里我想谈谈一些性能测试参数的相关知识。当然,也不是一篇博文就能说清道明的。只希望在你的测试道路上能给你一丝帮助。

  不怕啰嗦的再次忠告,那想成为测试高手的新人,多学学基础知识。别把过多的时间放在研究新工具的使用上。工具何其多,原理差不多。不要本末倒置了。也算是自我提醒吧!

  性能测试常见指标

  性能测试说白了就是通过工具模拟多个用户对被测系统进行访问。然后查看系统对于多个用户发来请求的处理能力。

  左边的两个小人表示两个用户,向右边服务器发送请求,然后得到服务器的响应信息。

  首先,我们要保证向服务器发送的请求的正确性,当然用户向服务器发送错误的请求,服务器也会个客户端响应信息,但响应的是报错信息;所以,为了保证测试数据的有效性,我们的要保证发送请求的正确性。

  为什么一般的性能测试要在局域进行?

  一般我们的性能测试都是在局域网中进行的。为什么一定要在局域网中进行呢?因为局域网中不受网络限制。这个说法不能绝对。但是一般测试工具的用户并发量是不会受到局域网带宽的限制,除非你做的是十万,百万级别的用户并发。相信懂一点网络知识的人都知道,当你上网很慢的时候,比如打开某某网站很慢,你肯定会骂电信的网络不给力,而不会骂这个网站响应速度不给力。因为,请求信息的耗时大部耗在传输过程中。

  所以,刚做测试时,我们群里热议论,如果我们每个人都开一个压力工具对百度网站进行加压。百度,服务器会不会挂掉。有测友说这样是不道德人。呵呵!其实,完全不必有这个担心。就一般人家用的带宽,我确保,你向百度服务器发送的请求大部分都死在半路上,就算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以,做性能测试不了解被测系统的架构,以及各种技术的性能。很难做出有效的测试报告。

  下面我们看看性能测试的一些技术指标。

  Work Load = Virtual Users

  工作负荷 = 虚拟用户数

  对服务器产生多大压力,可以由多少用户同时对服务器发送请求来衡量。也就是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。

  虚拟用户数可以用进程或线程的方式进行模拟。

  response time 响应时间

  从客户端将数据包发出,到接收到服务器端发来的请求。这个过程的总体时间叫response time

  这个时间用来衡量的处理请求的速度(抛出网速限制的前提下)

  throughput ~Ti & To

  这个表示,吞吐量,吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1个用户跑100天的吞吐量大。所以,我们要想看系统的性能应该用“吞吐率”,就是单位时间的吞吐量,比如吞吐量/秒。

  站在服务器端,T-in表示“吞”;T-out表求“吐”

  Ti:T-in 主要衡量客户端的能力,看客户端往服务器发送的请求数据包的吞吐率。

  To: T-out 主要衡量的服务器端的能力,看服务器处理返回请求数据包的吞吐率。

  Hits/Request

  网页点击数/请求

  Response/Successful Response

  响应/成功的响应

  Request与Response是对应,一个请求对应一个响应。但当客户端对服务器的压力达到一直程度后,不是每一请求都能得到响应的。去年末火了个最牛B的“电子商务”网站。12306(铁路网上订票系统),虽然有很差的用户体验,但每天还是大把的人拼命的登录(过年回家的人伤不起),甚至用外挂登录。见有网友云云点击(请求)了几十几百次才订票(响应)成功。所以,成功响应率也是很重要的一个指标。客户端发送一千个请求的成功得到响应的几率。

  Hits Per Second

  每秒中点击次数

  和吞吐量一样,单单用点击数(hits)来衡量系统也是不合理的。所以,用每秒钟的点击数才能衡量出服务器的处理能力。

  响应时间图分析

  横坐标表示用户数

  纵坐标表示时间

  红色虚线,表求的是一种系统的理想状态。

  当服务器处理10个用户请求时所用的时间是2秒(假设),当服务器处理200用户请求时所用的时间也是2秒。所以说这种状态是一种理想的状态。现实中,不管是如何超级强的服务器当用户数达到一定数量时,响应时间必会变慢。

  蓝色斜线,是服务器常见的一种曲线状态。

  服务器的响应时间虽然用户数量的增加逐渐变慢。

  当系统出现这种斜线,应该说系统性能是相当健壮的。随着用户的增长响应时间逐渐变长。

  黑色曲线,个人觉得是服务器处理能力的真实曲线状态。

  为什么说黑线才是真实服务器处理能力的曲线呢?当用户处理一个用户请求是2秒(假设),当处两个用户请求是马上变成3秒(假设),当处理3个用户请求时变成4秒(假设)。再差的服务器也有个处理范围,比如是,100用户同时并发,服务器可以轻松应对,不管是10个用户还是80个用户同时请求,服务器都可以即可响应(请参考理发店模式)。只有当用户数量达到某个数量点后,服务器性能急剧下降。如上图黑色十字星处就是系统的拐角点。

  我们假设有一个门,在一个时间点上可同时过10个人,不管你是同时来3个还是10个都可以在同一时间点过门,假如来了11个人,必然有一个人要等10个人过门之后才能过。那么当超过10人来过门时,过门的速度就开始变慢。那么10就是服务器性能的拐角点。我们通常做压力测试找服务器的拐角点是很重要的任务之一。

原文转自:http://www.ltesting.net