Chinaunix首页 | 论坛 | 博客
  • 博客访问: 341189
  • 博文数量: 32
  • 博客积分: 1470
  • 博客等级: 上尉
  • 技术积分: 575
  • 用 户 组: 普通用户
  • 注册时间: 2006-05-31 11:38
个人简介

实践主义者,多行路远胜于多读书。

文章分类

分类: LINUX

2006-08-25 16:43:08

由于想再提升原有系统中文件传输模块的速度,并减少系统资源占用,进行了一次sendfile()的性能测试,但失败了.不过还是将它用在了模块中.记录一下这次失改的微调测试.
 
运行平台: 客户机与服务器均为P4计算机,IDE硬盘; Fedora5发行版; 百兆局域网;
 
接收端程序如下:

  FILE *fp = fopen(FILENAME,"wb");

  while((len = recv(sockfd, buff, sizeof(buff), 0)) > 0)
  {
      fwrite(buffer, 1, len, fp);
  }
  fclose(fp);

 
 
A. 发送端传统方式代码段如下:
  fd = open(FILENAME, O_RDONLY);
  while((len =read(fd, buff, sizeof(buff))) >0) 
  {
       send(sockfd, buff, len ,0);
  }
  close(fd);  

由于我磁盘分区时指定的块大小为4096,为了最优读取磁盘数据,buff大小设为4096字节.但在测试中发现设为1024或8192不会对传输速度带来影响.

文件大小:9M; 耗时:0.71 - 0.76秒;
文件大小:32M; 耗时:2.64 - 2.68秒;
文件大小:64M; 耗时:5.36 - 5.43秒;

B. 使用sendfile()传输代码段.

  off_t offset = 0;
  stat(FILENAME, &filestat);

  fd = open(FILENAME, O_RDONLY);
  sendfile(sockfd, fd, &offset, filestat.st_size) );
  close(fd);  

文件大小:9M; 耗时:0.71 - 1.08秒;
文件大小:32M; 耗时:2.66 - 2.74秒;
文件大小:64M; 耗时:5.43 - 6.64秒;

似乎还略有下降.根据sendfile的man手册,我在使用该函数前调用了

 int no = 1;
 printf("%d\n", setsockopt(sockfd, IPPROTO_TCP, TCP_CORK, (char*)&no, sizeof(int)) );

文件大小:9M; 耗时:0.72 - 0.75秒;
文件大小:32M; 耗时:2.66 - 2.68秒;
文件大小:64M; 耗时:5.38 - 5.60秒;

这样似乎达到了传统方式的速度?!不管哪种环境下,我用ethereal抓包显示每一个tcp包的playload部分最大也通常是1448字节.

看来我的测试没有体现出"应用层数据的两次拷贝带来很大的消耗"这一说法.如果按照存在就是有理的说法的话,那我想sendfile()在两种情况下才体现优势,但我却没有环境测试:
1. 大并发量的文件服务器或HTTP服务器;
2. 内存资源紧张的嵌入式系统;

另外,网络上大量的关于tcp选项中的TCP_CORK描述已经过时.在man手册中早已提到该参数可以与TCP_NODELAY结合使用了.只是,只要设置了TCP_NODELAY选项后,不管是否设置TCP_CORK,包都会立即发出.



补充:

TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”,Nagle化在这里的含义是采用Nagle算法把较小的包组装为更大的帧。 John Nagle是Nagle算法的发明人,后者就是用他的名字来命名的,他在1984年首次用这种方法来尝试解决福特汽车公司的网络拥塞问题(欲了 解详情请参看IETF RFC 896)。他解决的问题就是所谓的silly window syndrome ,中文称“愚蠢窗口症候群”,具体含义 是,因为普遍终端应用程序每产生一次击键操作就会发送一个包,而典型情况下一个包会拥有一个字节的数据载荷以及40个字节长的包头,于是产生4000%的 过载,很轻易地就能令网络发生拥塞,。 Nagle化后来成了一种标准并且立即在因特网上得以实现。它现在已经成为缺省配置了,但在我们看来,有些场合下 把这一选项关掉也是合乎需要的。

现在让我们假设某个应用程序发出了一个请求,希望发送小块数据。我们可以选择立即发送数据或者等待产生更多的数据然后再一次发送两种策略。如果我 们马上发送数据,那么交互性的以及客户/服务器型的应用程序将极大地受益。例如,当我们正在发送一个较短的请求并且等候较大的响应时,相关过载与传输的数 据总量相比就会比较低,而且,如果请求立即发出那么响应时间也会快一些。以上操作可以通过设置套接字的TCP_NODELAY选项来完成,这样就禁用了 Nagle算法。

另外一种情况则需要我们等到数据量达到最大时才通过网络一次发送全部数据,这种数据传输方式有益于大量数据的通信性能,典型的应用就是文件服务 器。应用Nagle算法在这种情况下就会产生问题。但是,如果你正在发送大量数据,你可以设置TCP_CORK选项禁用Nagle化,其方式正好同 TCP_NODELAY相反(TCP_CORK 和 TCP_NODELAY 是互相排斥的)。下面就让我们仔细分析下其工作原理。

假设应用程序使用sendfile()函数来转移大量数据。应用协议通常要求发送某些信息来预先解释数据,这些信息其实就是报头内容。典型情况下 报头很小,而且套接字上设置了TCP_NODELAY。有报头的包将被立即传输,在某些情况下(取决于内部的包计数器),因为这个包成功地被对方收到后需 要请求对方确认。这样,大量数据的传输就会被推迟而且产生了不必要的网络流量交换。

但是,如果我们在套接字上设置了TCP_CORK(可以比喻为在管道上插入“塞子”)选项,具有报头的包就会填补大量的数据,所有的数据都根据大 小自动地通过包传输出去。当数据传输完成时,最好取消TCP_CORK 选项设置给连接“拔去塞子”以便任一部分的帧都能发送出去。这同“塞住”网络连接 同等重要。

总而言之,如果你肯定能一起发送多个数据集合(例如HTTP响应的头和正文),那么我们建议你设置TCP_CORK选项,这样在这些数据之间不存在延迟。能极大地有益于WWW、FTP以及文件服务器的性能,同时也简化了你的工作。

 

阅读(5286) | 评论(2) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-01-22 15:43:50

调优时有没有调整内核中tcp的选项 这里面的缓冲区也需要增加 另外使用sendfile应该是减少了系统调用数 如果使用/usr/bin/time 查看的话,所花费的时间应该减少