魔鬼藏在细节中

是的，我在这里想说的就是这句名言，Devils arein the details.

 

事情的来源是这样的，节前和几个同事在公司内部开了一门叫advancedperformance testing的多次课程，某次课后，我布置了一个homework。主要目的是练习性能测试中的几个概念，比如think time，assertion等。

 

考虑到是第一个homework，题目本身比较简单。

Task: Testthe performance of our web proxy.

Supposethere are 2 groups of users.

1. Tech guys(40%)

http://www.sina.com.cn/ -->http://tech.sina.com.cn/ -->http://tech.sina.com.cn/internet/

2. News guys(60%)

http://www.sina.com.cn/ -->http://news.sina.com.cn/ -->http://news.sina.com.cn/world/

 

Shouldinclude:

Think time,web page result check.

-------------------------------------------------------------------------------

 

为了避免把事情弄复杂，没有涉及到POST和变量的操作，要求大家用JMeter来完成，提交jmx脚本和结果的截图，以及简单的说明。

 

其实布置这个作业的时候，我还比较担心是不是太简单了，起不到锻炼的作用。不过这两天在家把十几份作业全部run了一遍之后发现其实有很多值得探讨的地方，而且有些点自己之前也没有搞明白，虽然这个工具也用了好久。

 

下面我们来详细的说说细节的事儿。

1.     response time

这是一个看起来很简单但是实际比较复杂的指标，幸好这里还不涉及time to first byte之类的概念，也且先不管不同的分析方法，但是也发现有几类不同的统计方式。

a.  把上面每一个http request的时间统一来看，看到的是每一个request的响应时间。

b.  按不同的请求类型来看，例如homepage, tech, internet, news, world，然后看每类请求的响应时间。

c.  把每类用户的系列操作当成一个transaction来看，然后看整个transaction的响应时间。

在不结合需求的情况下，这些没有对错，关键看哪种是你想要的。

 

2.     Assertion

Assertion 在性能测试中，特别是WEB的性能测试中是很重要的校验手段。在看大家提交的脚本中发现有几种做法。

a.  检查response的body中是否有“新浪首页”字样，这也是最多的一种做法。这种做法很直接，但是可能会稍显单薄，因为动不动几百KB的body，别的页面也可能有这样的字眼。当然我们也可以加多个这样的关键字。

b.  检查HTML格式的内容，比如“<title>新浪首页</title>”，这种可能比纯粹检查关键字要好一点。

c.  检查response header。比如check host是sina.com.cn,并且HTTP code是200。这个方法看起来不错，但是可能会有一个很大的问题就是，现在很多网站的错误页面也看起来像是一个正常的页面，而且返回码都看起来是正常的。这也是设置assertion所想要避免的一个问题。因为工具本身就可以自动的根据code来判断成功还是失败。

 

3.     Recording

录制是创建脚本的一种常用的方法，JMeter提供基于proxy的录制的功能，当然也可以借助于badbody之类的工具来完成。于是我们也可以借助录制来获得上面题目需要的脚本，也确实有人这么做。

 

看到上面的脚本，虽然运行起来可以work，会发现有些问题，首先是太过与复杂，难以维护，其次是依赖性太强，因为很多是具体的元素的URL,比如某个图片，某个广告动画，这些东西是变动很快的，那么下次脚本就可能会实效。

 

4.     Think time

这是一个性能测试中比较基本的概念，结合到JMeter中，发现大家用了两种不的方法来实现。一种适用test action中的threadpause，另一种适用constant timer。问题是两种效果是一样的吗？都能达到我们想要的目的吗？

我也拿不准，所以做了个实验。

 

关于Thread pause:

涉及一个test plan, 流程是这样的：GETgoogle.cn--> thread pause 5s --> GETgoogle.cn--> thread pause 5s

 

 

Test with thread pause

 

 

 

得到的结果是。

结合数据里面的时间戳，发现基本是安装我们设想的那样来运作，每完成一次请求之后sleep5s。

 

关于Constant timer:

设计的流程是：GETgoogle.cn--> Constanttimer 5s --> GETgoogle.cn--> Constanttimer 5s

 

 

得到的结果如下：

仔细看一下，和上面的解雇完全不同，每一个请求之间间隔了10s，正好是两个timer加起来的时间，所以这个timer不是很多人设想的那样在每次请求之后sleep 5s，而是这种看起来很奇怪的行为。我试验了好几次，包括把timer放在thread group的不同的位置。

 

我想可能不少人对于这个结果都比较surprise，如果是这样的话测试出来的结果就会差很多，这也是在做virtual user creation很担心发生的问题，模拟出来的用户行为和我们想要的很不一样。

 

联想到上次文章中提到的性能测试要求宏观，也很强调微观，特别是一些critical details。是的，魔鬼就藏在细节中，技术的精进也是在于细节中，共勉。