SendToQueue这个方式的发送是否没有起到缓冲作用？

[EquentR]

大佬们好，请教一个问题
在connection对象中，用来缓冲队列发送的Writer最终调用的还是阻塞的Send方法，这个方法直接调用底层的TCP连接，如果发送的数据包不大，而且发送较为频繁的话（例如一秒几万个数据包，且每个数据包大小可能远达不到1kib），那么频繁地进行系统调用，在内核态和用户态切换会造成大量的时间消耗，且无法充分利用带宽。通过pprof/profile分析结果也确实如此，大量时间消耗在tcp.Write中，这里是否可以给TcpConn连接加入bufio+锁+定时器flush的方式来增加带宽利用率？

// StartWriter is the goroutine that writes messages to the client
// (写消息Goroutine， 用户将数据发送给客户端)
func (c *Connection) StartWriter() {
	zlog.Ins().InfoF("Writer Goroutine is running")
	defer zlog.Ins().InfoF("%s [conn Writer exit!]", c.RemoteAddr().String())

	for {
		select {
		case data, ok := <-c.msgBuffChan:
			if ok {
                                // ！！！！此处
				if err := c.Send(data); err != nil {
					zlog.Ins().ErrorF("Send Buff Data error:, %s Conn Writer exit", err)
					break
				}

			} else {
				zlog.Ins().ErrorF("msgBuffChan is Closed")
				break
			}
		case <-c.ctx.Done():
			return
		}
	}
}

附：pprof

[YanHeDoki]

理论上这里确实可以先收集一批次的 buf 里面的 msg 然后一次性写入的但是我记得是因为什么问题改成了现在这样

[YanHeDoki]

好像是直接用 Tcpconn 写入的话会出现连接已经关闭但是 sendbuf 中还存在消息的情况

[EquentR]

但是不管哪种方式好像都会导致连接关闭了，send buf chan还有消息啊，缓冲发送似乎无法避免这个问题，毕竟连接确实被关掉了，然后就只能重连，那么产生新的连接对象后，原本的chan也需要额外的手段继承过来😂。感觉还是直接使用bufio累计到一定数量自动发送或定时器超时后将bufio flush一下比较合理

[YanHeDoki]

但是不管哪种方式好像都会导致连接关闭了，send buf chan还有消息啊，缓冲发送似乎无法避免这个问题，毕竟连接确实被关掉了，然后就只能重连，那么产生新的连接对象后，原本的chan也需要额外的手段继承过来😂。感觉还是直接使用bufio累计到一定数量自动发送或定时器超时后将bufio flush一下比较合理

可以提个 pr 看一下，理论上这里是确实可以优化的

[EquentR]

好，我试着改一下

[1426919587]

首先第一点go的send方法并不是阻塞的，不是传统意义上c的那种send阻塞，直到发送成功才返回，他是有一个for循环，每次发送指定字节，然后全部发送完，但是它底层的send是一个非阻塞函数，它的阻塞在比如你填的send的长度是4096，它一次发送1024，就for4次循环，sendsync的那种。小包多，是可能会频繁进入内核send，如果收集起来一次发送，但是它不能及时反应，其实tcp的内核也有Nagle算法，它也会产生其他的问题，就看你怎么取舍了