TCP Nagle's  算法导致的性能问题

最近再用sysbench给DBScale做压力测试的时候发现 DBScale+单个MySQL 的读TPS比单个MySQL要差很多。
跟踪代码后发现DBScale每次执行完一条select语句之后从客户端recv第一个数据包的时间要比第2个数据包的时间多200倍。

查看了TCP的协议发现:

1. TCP会默认开启Nagle's  算法
      该算法会将多次send的操作(连续的,数据量小的)缓存到操作系统的发送缓冲中,当执行第一个recv的时候会想将发送缓存中的数据发送出去,然后再接收。

2. 两个recv直接多个连续的send操作会触发Nagle's  算法
      例如:
  peer.send_n ("GET ", 4);
  peer.send_n (pathname, strlen (pathname));
  peer.send_n (" HTTP/1.0\r\n\r\n", 13);

DBScale在处理查询结果集包的策略是尽快地将服务端返回的数据包发送给客户端,所以必然会有多次send操作,从而触发Nagle's  算法。

之所以读TPS上不去是因为DBScale将查询结果返回给sysbench客户端的时间被Nagle's  算法delay了。

该问题的解决办法如下:
1. 为socket设置选项 TCP_NODELAY
ACE的socket设置代码如下:
  int nodelay = 1;
  stream->set_option(ACE_IPPROTO_TCP, TCP_NODELAY, &nodelay, sizeof (nodelay);

2. 代码添加代码对多个send操作进行缓存,


转载请注明转自高孝鑫的博客
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值