首页 > 默认 > 千M网络-实际应用中传输速度测试

千M网络-实际应用中传输速度测试

千M网络在实际应用中究竟能给我们的传输速度带来多大的提高呢?

理论上千M网络的速度可以达到1000M bit (大约100M byte)的速度,以下的讨论中,如果不做特别说明速度均是针对Byte而言的。也就是说千M网络的传输速度上限是100M/秒。

在实际应用中受各种因素(包括硬盘读写速度,操作系统文件读写处理,传输软件本身的设计等等)的影响,速度要大打折扣。我们这里做了几个试验来看看效果:

首先要准备网络环境:

1)参与测试的各台电脑均是 千M网卡(现在大多数机器默认的配置都是千M网卡,本次测试使用1台1U的服务器,2台笔记本电脑)。

2)各台机器连接到千M网络交换机(本次测试使用D-link DGS-1008D)。

3)网线均使用6类线,按照千M标准制作水晶头(本次测试均使用机器制造的网络连接线,是非常标准的)。

网络拓扑:

测试网络拓扑 

 

试验1:使用IPMSG在两台windows xp的笔记本电脑之间传输1个4G的文件,笔记本1上只有1个硬盘-A盘,笔记本2上有两个硬盘A盘和B盘(这两个硬盘的读写速度有差异);

笔记本1的硬盘A读速度是:21M/秒(笔记本电脑)

--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
      Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

   Sequential Read :   21.571 MB/s
  Sequential Write :   21.755 MB/s
 Random Read 512KB :   15.581 MB/s
Random Write 512KB :   17.073 MB/s
   Random Read 4KB :    0.409 MB/s
  Random Write 4KB :    0.546 MB/s

         Test Size : 100 MB
              Date : 2009/10/06 17:21:40

 笔记本2的硬盘A的写速度是20M/秒

--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
      Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

   Sequential Read :   22.360 MB/s
  Sequential Write :   20.107 MB/s
 Random Read 512KB :   13.962 MB/s
Random Write 512KB :   13.882 MB/s
   Random Read 4KB :    0.297 MB/s
  Random Write 4KB :    0.708 MB/s

         Test Size : 100 MB
              Date : 2009/10/06 17:07:15

笔记本2的硬盘B的写速度是:31M/秒

--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
      Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

   Sequential Read :   33.733 MB/s
  Sequential Write :   31.385 MB/s
 Random Read 512KB :   13.111 MB/s
Random Write 512KB :   12.700 MB/s
   Random Read 4KB :    0.262 MB/s
  Random Write 4KB :    0.598 MB/s

         Test Size : 100 MB
              Date : 2009/10/06 17:03:06

1.1 笔记本1-> 笔记本2的A 盘的IPmsg 试验传输速度是16M/秒

平均速度16M

1.2 笔记本1-> 笔记本2的B盘 的IPmsg 试验传输速度是19M/秒

平均速度19M

这次试验结果表明:

1)Ipmsg 软件本身对网络速度有很好的支撑。

2)传输速度受到源、目标机器的硬盘读写速度影响明显。受CPU负载影响不明显,因为我们发现ipmsg在传输的时候,CPU负载并不是很高,大概在60%. 在1.2的试验中,网络传输速度基本达到了源机器硬盘的极限(因为实际读文件可能不是完全的sequence读)。

 

实验2:在笔记本2的磁盘B ->1U服务器(Linux服务器)上的xp虚拟机的磁盘B (虚拟磁盘vmdk)之间通过Ipmsg传输4G的文件。

xp虚拟机的磁盘B的读写速度相当惊人(估计不准):

--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
      Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

   Sequential Read :  257.509 MB/s
  Sequential Write :  306.054 MB/s
 Random Read 512KB :  188.512 MB/s
Random Write 512KB :  236.181 MB/s
   Random Read 4KB :   14.724 MB/s
  Random Write 4KB :   14.341 MB/s

         Test Size : 100 MB
              Date : 2009/10/06 19:07:10

2.1 笔记本2的磁盘B-> 虚拟机(单CPU)的磁盘B的IPmsg 试验传输速度是14.5M/秒

笔记本-to-xp-linu-14.5M

2.2笔记本2的磁盘B-> 虚拟机(双CPU)的磁盘B的IPmsg 试验传输速度是14.8M/秒

笔记本-to-xp-linu-2CPU-14.8M

2.3 虚拟机(单CPU)的磁盘B->笔记本2的磁盘B 的IPmsg 试验传输速度是18.4M/秒

虚拟机-to-笔记本-18.4M-CPU负载

这次试验结果说明:

1、本来想借助于1U 服务器上的高速磁盘IO(75M/秒)来构造一个具有高速读写速度的虚拟XP , 用以和笔记本2之间进行传输,期望达到> 20M/秒的。结果令人失望。 可能是xp的虚拟机不能充分利用Host 的磁盘IO(Linux的guest虚拟机基本可以达到与host相同的IO速度)(备注这里讨论的虚拟磁盘vmdk未做特别说明均指Pre-allocate类型的)

2.4 笔记本2上构建的RamDisk -> 虚拟机(单CPU)上构建的RamDisk 的IPmsg 试验传输速度是25.1M/秒

RamDisk测试-25M

虚拟机上的CPU已经被消耗100%了,如果虚拟机的CPU再强一点会不会更快?(这个问题以后再探索)

 

2.5 笔记本2上构建的RamDisk -> 虚拟机(双CPU)上构建的RamDisk 的IPmsg 试验传输速度是23.5M/秒

RamDisk测试-23.5M

给虚拟机上双CPU,结果速度反而不如单CPU, 是否ipmsg 或者Ramdisk对双Cpu支持不行?(以后再探索)

2.4 和 2.5结果表明1000M网的传输速度潜力很大,提高主要还是依赖于两端的设备IO速度。;;RamDisk to Ramdisk 是我等能构建的最快的端设备了。速度也就是25M而已。

 

实验3:SecureFx  测试:

3.1在笔记本1的磁盘A ->1U服务器(Linux服务器)之间通过SecureFx传输4G的文件。

结果速度与100M差不多。Cpu已经耗尽了.(Cpu 是奔腾Mobile 1.3G 的)

SecurFx-百分百CPU

3.2 在笔记本2的磁盘B ->1U服务器(Linux服务器)之间通过SecureFx传输4G的文件。

结果速度与100M差不多,Cpu 没有耗尽。速度比笔记本1还差,只有6M/秒。其中原因比较奇怪。没有参考价值。

 

试验4:CuteFTP测试

4.1 在笔记本2的磁盘B ->1U服务器(Linux服务器)之间通过CuteFTP传输4G的文件。速度为12.5M/秒

客户端CPU已经是瓶颈:

cuteftp-12M-客户端CPU负载

服务端CPU还有空间,但也消耗很大:

cuteftp-12M-服务端CPU负载

这个实验表明对于CuteFtp来说,两端的硬盘速度未能达到极限。客户端CPU是个瓶颈。

 

 

关于作者:

昵称:商云方
档案信息:顾问, HAND张江技术中心
联系方式:你可以通过yunfang.shang@hand-china.com联系作者
点击查看商云方发表过的所有文章...
本文永久链接: http://blog.retailsolution.cn/archives/2456

 

 

对本文的评价:

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

 

 

分类: 默认 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.
您必须在 登录 后才能发布评论.