前言
测试报告为测试MultiGet性能而做，分本机测试，局域网测试，互联网测试三个方面。
测试主要是对比其他类似软件来进行。选取的软件有：downloader for X (d4x)
，wxDfast，prozilla，wget，axel，downthemall等。
第一部分 本机测试
1.1 单地址性能测试
1.1.1 MultiGet 和 d4x, wxDfast的本地测试对比
测试日期：2006/10/17
软件：MultiGet 0.8.3 ， d4x 2.5.7.1 和 wxDfast 0.5.1
环境：本机上建立vsftp服务器，url地址ftp://localhost/49.rmvb，文件大小194580713
字节，内存512M，Ubuntu6.06
由于d4x不能解析localhost域名，在输入任务时用ftp://127.0.0.1/49.rmvb代替。
由于缓存的原因，采用交叉轮换测试取平均值。
第一次测试（5线程）
测试序号
|
测试程序
|
开始时间
|
结束时间
|
耗时
|
平均速度
|
1
|
MultiGet
|
18:04:02
|
18:04:54
|
52s
|
3654K/s
|
2
|
d4x
|
18:07:43
|
18:08:28
|
45s
|
4223K/s
|
3
|
MultiGet
|
18:10:12
|
18:13:03
|
51s
|
3726K/s
|
4
|
d4x |
18:16:10
|
18:16:55
|
45s
|
4223K/s
|
5
|
MultiGet
|
18:20:05
|
18:20:43
|
38s
|
5001K/s
|
6
|
d4x |
18:21:56
|
18:22:46
|
50s
|
3800K/s
|
第二次测试（5线程）
| 测试序号 |
测试程序 |
开始时间 |
结束时间 |
耗时 |
平均速度 |
1
|
d4x
|
19:57:22
|
19:58:09
|
47s
|
4043K/s
|
2
|
MultiGet |
19:59:24
|
20:00:09
|
45s
|
4223K/s |
3
|
d4x
|
20:01:20
|
20:02:09
|
49s
|
3878K/s
|
4
|
MultiGet
|
20:04:02
|
20:05:03
|
61s
|
3115K/s
|
5
|
d4x
|
20:09:02
|
20:10:08
|
66s
|
2879K/s
|
6
|
MultiGet
|
20:11:44
|
20:12:44
|
60s
|
3167K/s
|
第三次测试（5线程）
| 测试序号 |
测试程序 |
开始时间 |
结束时间 |
耗时 |
平均速度 |
1
|
wxdfast
|
20:16:23
|
20:19:49
|
206s
|
922K/s
|
结论：可以看出wxdfast对于高速下载性能不佳，这应该归功于wxSocket
性能不佳。在头两次测试中，MultiGet和d4x的总耗时为307s和312s，MultiGet略短于d4x的总耗时。性能大体相当。在本机测试中
内存和硬盘可能都会成为瓶颈，所以数据有比较大的波动。
1.1.2 MultiGet 和 prozilla 的本地测试对比
测试日期：2006/10/19
软件：MultiGet 0.8.3 ， prozilla(proz) v2.0.4
环境：同上
第一次测试（5线程）
测试序号
|
测试程序
|
开始时间
|
结束时间
|
耗时
|
平均速度
|
1
|
proz
|
19:57:00
|
19:57:56
|
56s
|
3393K/s
|
2
|
MultiGet
|
19:59:17
|
20:00:05
|
48s
|
3958K/s
|
3
|
proz
|
20:01:00
|
20:01:55
|
55s
|
3455K/s
|
4
|
MultiGet |
20:03:16
|
20:04:03
|
47s
|
4043K/s
|
5
|
proz |
20:04:30
|
20:05:26
|
56s
|
3393K/s
|
6
|
MultiGet |
20:07:19
|
20:08:07
|
48s
|
3958K/s |
结论：因为结果相差比较明显，没有像测试d4x的对比一样再做一次循环测试。
prozilla在大流量下处理速度逊色于MultiGet约15％，也逊色于d4x的处理能力。
1.2 本机多地址测试（待完成）
第二部分 局域网测试
2.1 单地址测试
测试一：
测试日期：2006/10/26
测试环境：服务器192.168.0.8，有线连接到路由器，FC3，512M，2.4G
客户端192.168.0.10，无线连接到路由器，Ubuntu 6.06，512M，1.7G
测试软件：MultiGet beta2，d4x 2.5.7.1，wxdfast，prozilla，axel
测试地址：http://192.168.0.8/testdown/01.rmvb 文件大小319535925字节 不限连接数
所有测试都是5线程下载。
数据：
测试编号
|
软件
|
开始时间
|
结束时间
|
完成任务用时
|
1
|
MultiGet
|
16:31:03 |
16:33:27 |
144s
|
2
|
d4x
|
16:35:46 |
16:37:54 |
128s
|
3
|
MultiGet
|
16:38:46 |
16:41:13 |
147s
|
4
|
d4x
|
16:43:22 |
16:45:45 |
143s
|
5
|
wxdfast
|
16:47:45 |
16:56:11 |
506s
|
6
|
axel
|
16:59:30 |
17:01:52 |
142s
|
7
|
proz
|
17:03:38 |
17:06:12 |
154s
|
8
|
d4x
|
17:08:40 |
17:11:06 |
146s
|
9
|
MultiGet
|
17:11:53 |
17:14:13 |
140s
|
结论：wxDfast在高速下载时仍是弱项，速度在620K/s左右上不去，其他数据基本接近，似乎proz略差些。因为有一个无线连接，可能会有速度上
的波动。所以个人怀疑第2个数据可能是有部分网络速度的波动影响，如果剔除2，5两个数据，其他的数据相差都不太远。总体上看，各种下载工具在这个测试环
境下表现都很接近。
2.2 多地址测试
暂未完成。
第三部分 互联网测试
3.1 单地址测试
3.1.1 MultiGet 对比 d4x
(5线程下载)
测试一：
测试时间：2006/10/18 17:00
软件：MultiGet 0.8.3 vs d4x 2.5.7.1
d4x不能给任务添加多个镜像地址，虽然有搜索服务，但在我这里打开这个功能经常崩溃，所以没办法对比多址下载，只对比单址下载吧。
首先挑选一个不限制连接数量的源，然后同时开始下载，观察各自的进度。
我选：
http://mirror.mcs.anl.gov/yellowdog/iso/yellowdog-4.1-sagitta-20060202-install1.iso
文件长度671797248字节
先点d4x的确定，后不到1秒点MultiGet确定。
开始任务后，两者完成度比较接近，在3％时，MultiGet比d4x领先约10K，8％时d4x领先约4.5M，16％左右时两者持平，30％时
MultiGet领先约0.3M，40％时d4x领先约2M，50％
时d4x领先约4.1M，60％时d4x领先约4.9M，70％时d4x领先约3.8M，MultiGet完成600M时，d4x完成614M，领先
14M，最终结果如下：
|
开始时间
|
结束时间
|
平均速度
|
MultiGet 0.8.3
|
16：37：03
|
18：33：14
|
94.11Kb/s
|
d4x 2.5.7.1
|
16：37：03
|
18：30：49
|
96.11Kb/s
|
结论：MultiGet和d4x速度接近，平均速度相差2%，可能是
MultiGet处理包的速度略差，也可能是网络波动恰好倾向于d4x，对于互联网的情况，这样的波动范围应该可以接受，以一次的测试无法得出结论说
MultiGet速度比d4x差，可能需要更科学的方法或更多次的平均才可以下结论。我将在以后多做几次类似的测试。
测试二：
测试时间：2006/10/22 20:31
软件：MultiGet 0.8.5 vs d4x 2.5.7.1
这次我选这个地址来对比：
http://mirror.lupaworld.com/redhat/shrike-i386-disc1.iso
文件长度669122560字节，这个地址不限连接，两个测试程序都可以达到5个连接数。
结果非常戏剧性，两者运行时间完全相同。中间段互有领先，但幅度都很小。
|
开始时间
|
结束时间
|
平均速度
|
MultiGet 0.8.3
|
20:31:58
|
22:13:37
|
没计算
|
d4x 2.5.7.1
|
20:31:58
|
22:13:37
|
没计算 |
结论：MultiGet 和 d4x
单地址下载情况下性能太接近了，每次测试都差不多，这次更加巧合。可惜不能对比d4x的多地址下载。这次查了MD5，两个都对。
3.1.2 MultiGet 0.8.5 对比 prozilla
(5线程下载)
测试时间：2006/10/22 10:15
prozgui在我的机器上不能正确运行（添加任务就死），所以选控制台界面的prozilla来做比较测试，这次选择国内的源来做
http://mirror.lupaworld.com/redhat/shrike-i386-disc1.iso
文件长度669122560字节，这个地址不限连接，两个测试程序都可以达到5个连接数。
先运行proz，后不到1秒点MultiGet确定。
记录到各自的完成比例对比如下：
| 数据记录点 |
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
MultiGet 0.8.3
|
10%
|
20%
|
30%
|
40%
|
50%
|
60%
|
70%
|
80%
|
90%
|
100%
|
proz v2.0.4
|
9.2%
|
17.7%
|
27.2%
|
36.9%
|
46.7%
|
56.8%
|
66.5%
|
76.7%
|
86.5%
|
96.2%
|
运行时间：
MultiGet 10:15:50 -> 10:33:22=1042s 平均速度=627Kb/s
proz 10:15:50 ->
10:35:13=1163s 平均速度= 562Kb/s
proz速度比MultiGet差约10％
结论：proz的速度似乎比MultiGet略差，当然在互联网测试，数据是容易出
现波动的，不能以一次测试下定论，我没有连续再做一次同样的测试，因为这个下载地址太快了，测试时占用了我的太多带宽，两个同时运行时接近
1200Kb/s的速度，我怕再次烧了路由器。
3.2 多地址测试
3.2.1 MultiGet 0.8.3 对比 wxDfast 0.5.1（5线程下载）
测试时间：2006/10/17 约23：00
测试选取如下7个镜像地址，都是国外的源：
ftp://ftp.netrunner.nu/pub/desktopbsd/DesktopBSD-1.0-x86-CD.iso
ftp://ftp2.genotec.ch/pub/DesktopBSD/DesktopBSD-1.0-x86-CD.iso
ftp://ftp.solnet.ch/mirror/DesktopBSD/pub/DesktopBSD-1.0-x86-CD.iso
ftp://ftp.cs.pu.edu.tw/BSD/DesktopBSD/pub/DesktopBSD-1.0-x86-CD.iso
ftp://ftp.xenophase.net/mirrors/DesktopBSD/DesktopBSD-1.0-x86-CD.iso
ftp://ftp.ussg.iu.edu/pub/DesktopBSD/DesktopBSD-1.0-x86-CD.iso
ftp://desktopbsd.mirrors.tds.net/pub/desktopbsd/DesktopBSD-1.0-x86-CD.iso
同时(wxdfast提前大约1秒)运行wxdfast和MultiGet，这是考虑到网络情况在不同时间有不同的状况，同时运行才有一定
的可比较性。两个程序都设置成5线程下载。程序开始后，MultiGet逐渐领先于wxdfast，从领先％1开始，一路增加领先度，在MultiGet
完成50％时，我开始记录各自的完成比例如下：
数据记录点
|
1
|
2
|
3
|
4
|
5
|
MultiGet
|
50％
|
60％
|
70％
|
80％
|
90％
|
wxDfast
|
41％
|
49％
|
57％
|
67％
|
75％
|
结论：MultiGet在处理多地址下载时，性能远胜于wxDfast，这主要是MultiGet采用动态任务切换和动态地址切换，能够自动优选地址，而
wxDfast静态分片任务，完成后线程退出，且不会动态优选好的地址。而且当MultiGet接近完成时，wxDfast没和我打招呼，从我的眼前彻底
消失了，最后一个数据点因此没有取到。在wxDfast意外退出后，我终止了MultiGet下载。
3.2.2 MultiGet 0.8.3 对比 axel
v1.0b（5线程下载）
测试时间：2006/10/18 19:10:25
同时(MultiGet提前大约1秒)运行axel和MultiGet，这是考虑到网
络情况在不同时间有不同的状况，同时运行才
有一定的可比较性。两个程序都设置成5线程下载。程序开始后，10%时基本持平，从此一路领先，记录各自的完成比例如下：
| 数据记录点 |
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
MultiGet 0.8.3
|
10%
|
20%
|
30%
|
40%
|
50%
|
60%
|
72%
|
80%
|
90%
|
100%
|
axel 1.0b
|
10%
|
18%
|
26%
|
35%
|
44%
|
53%
|
63%
|
65%
|
70%
|
74%
|
MultiGet完成后axel继续运行。实际使用时间如下：
MultiGet运行时间: 19:10:25--20:48:31
axel运行时间：19:10:25--21:24:00(到此刻仅完成84％，只有三个线程在工作中，不等它结束了。)
结论：axel采用的任务分配算法和wxdfast类似，都是静态的任务分片，线程完成自己的任务片后就退出了，这使得程序在后半段的速度差距尤其明显。
至于是否会自动地筛选地址，因为axel没有输出相关信息所以没有观察到。
