分类: 系统运维
2008-03-11 18:17:26
原文地址 :
实际上 flood 的使用很简单,难的是如何模仿平时用户对你的站点的访问,我想这个应该可以
通过 提供的数据来定义吧,例如
=============== (下面开始是原文) ===============
对于新闻类站点的测试
对于如New York Times、Slashdot之类的新闻站点以及一些BLOG之类,它们都有一个主要的首页,首页上有着众多到栏目页和内容页的连接,对某条信息感兴趣的读者可以点进去仔细阅读。
通常情况下,这类站点的首页访问量相对固定而对于其它页面,访问量的变化就会更大一些。如果它推出了RSS/RDF订阅服务,那么就会出现一定量的直接到内容页的流量而不经过首页。大部分的此类站点都使用了某种内容的动态化技术,而Flood是测试这类动态站点的一个不错方法,特别你可以将之与一些静态站的响应相对比。
你可以用以下的参数设置模拟对一个新闻类型的网站的访问:
|
Farmer Set A |
Farmer Set B |
Farmer Set C |
URL List |
Homepage Only |
Homepage +3 stories |
3 story pages |
Repeat Count |
1 |
3 |
3 |
Count |
100 |
20 |
20 |
Start Count |
5 |
5 |
5 |
Start Delay |
1 |
5 |
5 |
Notes |
Home page only |
Homepage+Stories |
Stories only (RSS) |
测试在线商店站点
在线商店,在线商品目录或其它一些更具交互性的网站则有不同的使用模型。虽然仍会有一部分人到达你的首页,一些人会直接进入你站内的某一个页面,大多数用户会在你的站里找来找去,他们可能会在一个产品页上浏览大量的产品,进行一些搜索或者点击进入一些相关的产品页面。
因此,你应该用更大数量的地址列表测试这类站点,更大的重复次数(以模拟大量的用户)和相对新闻类站点比较低的并发访问数目:
|
Farmer Set |
URL List |
10-15 pages |
Repeat Count |
5 |
Count |
50 |
Start Count |
5 |
Start Delay |
5 |
测试 "Slashdot" 效应
有时,你必须测试你的系统能否应付某个特定时刻大量用户同时访问你的网站的情况。很多网站已经遇到过这个问题,一次重大事件中对于Slashdot网站的几个页面的引用就引发了对这个页面的巨量并发请求。
典型的情况下这些请求仅针对一个特殊的页面,我们可以通过在Flood中创建成百上千的家夫来并发请求服务器上的特定页面来模拟这种情况,通过设置高重复率和延迟系统来模拟一定时间内大量用户的连续访问。
|
Farmer Set |
URL List |
1 page |
Repeat Count |
50 |
Count |
250 |
Start Count |
100 |
Start Delay |
1 |
测试技巧
为了让以上各类测试都工作得很好,你应该记住以下几点:
●最重要的是,不要直接在WEB服务器上用Flood进行测试,如果你这样做你仅仅是在测试一台机器打开一个网络连接与自己通讯的能力,一定要在另一台机器上进行测试。
●要对自己机器的一些技术限制有所了解,这包括你机器容许的最大线程数和最大网络连接数,如果你试图创建超过这个限制的农夫将会带来让人难以理解的测试结果。
●Flood是一个客户端解决方案,因此对于在多台机器上进行测试没有任何限制。事实上我们推荐你这样做,因为这是一个在想进行饱和性测试时避免你的客户机系统的技术限制的好方法。
●Flood测试由于是在客户机上运行,它的表现也要依赖于客户的性能,如果客户机系统处于繁忙的状态,Flood进程会与其它客户进程一样被阻塞,因此,最好使用一台专用的客户机进行测试,如果客户机上还运行着其它任务,在开始测试之前最好关掉它们。