MultiGet文件下载器测试报告

sysnotdown

如果排版不当，请下载附件中的pfd.


测试报告中文版（尚未全部完成，将逐步添加和修改）


我主要选择d4x和wxdfast作为比较来测试，因为都是图形界面的程序，有一定的知名度，都有多地址下载功能，间或对比其他一些程序。


第一部分   本机测试

1.1 单地址性能测试

测试日期：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         10: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.2 本机多地址测试（待完成）


第二部分   局域网测试
环境没搭好，待完成。

第三部分   互联网测试

3.1 单地址测试

3.1.1 MultiGet 0.8.3 对比 d4x (5线程下载)

测试时间：2006/10/18 17:00

d4x不能给任务添加多个镜像地址，虽然有搜索服务，但在我这里打开这个功能经常崩溃，所以没办法对比多址下载，只对比单址下载吧。
首先挑选一个不限制连接数量的源，然后同时开始下载，观察各自的进度。
我选：
http://mirror.mcs.anl.gov/yellow ... 060202-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差，可能需要更科学的方法或更多次的平均才可以下结论。我将在以后多做几次类似的测试。

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/Deskt ... pBSD-1.0-x86-CD.iso
ftp://ftp.cs.pu.edu.tw/BSD/Deskt ... pBSD-1.0-x86-CD.iso
ftp://ftp.xenophase.net/mirrors/ ... pBSD-1.0-x86-CD.iso
ftp://ftp.ussg.iu.edu/pub/DesktopBSD/DesktopBSD-1.0-x86-CD.iso
ftp://desktopbsd.mirrors.tds.net ... pBSD-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没有输出相关信息所以没有观察到。

linuxcpp

赞！
如果能进Debian官方就好了