关于golang udp的高性能优化

前言:

     前段时间优化了golang udp client和server的性能问题,我在这里简单描述下udp服务的优化过程。当然,udp性能本就很高,就算不优化,也轻易可以到几十万的qps,但我们想更好的优化go udp server和client。

该文章后续仍在不断的更新修改中, 请移步到原文地 http://xiaorui.cc/?p=5684

UDP 存在粘包半包问题 ?

     我们知道应用程序之间的网络传输会存在粘包半包的问题。该问题的由来我这里就不描述了,大家去搜吧。使用tcp会存在该问题,而udp是不存在该问题的。
  为啥? tcp是无边界的,tcp是基于流传输的,tcp报头没有长度这个变量,而udp是有边界的,基于消息的,是可以解决粘包问题。udp协议里有16位来描述包的大小,16位决定他的数字最大数字是65536,除去udp头和ip头的大小,最大的包差不多是65507byte。

    但根据我们的测试,udp并没有完美的解决应用层粘包半包的问题。如果你的go udp server的读缓冲是1024,那么client发送的数据不能超过 server read buf定义的1024byte,不然还是要处理半包了。 如果发送的数据小于1024 byte,倒是不会出现粘包的问题。

在linux下借助strace发现syscall read fd的时候,就最大只获取1024个字节。这个1024就是上面配置的读缓冲大小。

下面是golang里socket fd read的源码,可以看到你传入多大的byte数组,他就syscall read多大的数据。

   http2为毛比http1的协议解析更快,是因为http2实现了header的hpack编码协议。thrift为啥比grpc快?单单对比协议结构体来说,thrift和protobuf的性能半斤八两,但对比网络应用层协议来说,thrift要更快。因为grpc是在http2上跑的,grpc server不仅要解析http2 header,还要解析http2 body,这个body就是protobuf数据。

  所以说,高效的应用层协议也是高性能服务的重要的一个标准。我们先前使用的是自定义的TLV编码,t是类型,l是length,v是数据。一般解决网络协议上的数据完整性差不多是这个思路。当然,我也是这么搞得。

如何优化udp应用协议上的开销?

  上面已经说了,udp在合理的size情况下是不需要依赖应用层协议解析包问题。那么我们只需要在client端控制send包的大小,server端控制接收大小,就可以节省应用层协议带来的性能高效。😁 别小看应用层协议的cpu消耗 !!!

解决golang udp的锁竞争问题

    在udp压力测试的时候,会发现client和server都跑不满cpu的情况。开始以为是golang udp server的问题,去掉所有相关的业务逻辑,只是单纯的做atomic计数,还是跑不满cpu。 通过go tool pprof的函数调用图以及火焰图,看不出问题所在。尝试使用iperf进行udp压测,golang udp server的压力直接干到了满负载。可以说是压力源不足。

  那么udp性能上不去的问题看似明显了,应该是golang udp client的问题了。我尝试在go udp client里增加了多协程写入,10个goroutine,100个goroutine,500个goroutine,都没有好的明显的提升效果,而且性能抖动很明显。 😅

  进一步排查问题,通过lsof分析client进程的描述符列表,client连接udp server只有一个连接。也就是说,500个协程共用一个连接。 接着使用strace做syscall系统调用统计,发现futex和pselect6系统调用特别多,这一看就是存在过大的锁竞争。翻看golang net 源代码,果然发现golang在往socket fd写入时,会存在写锁竞争。

怎么优化锁竞争 ?

实例化多个udp连接到一个数组池子里。。。在客户端代码里随机使用udp连接。这样就能减少锁的竞争了。

总结:

  udp性能调优的过程就是这样子了。简单说就两个点,一个是消除应用层协议带来的性能消耗,再一个是golang socket写锁带来的竞争。 当我们一些性能问题时,多使用perf、strace功能,再配合golang pprof 分析火焰图来分析问题。实在不行,直接干golang源码。 👌


对Golang感兴趣的朋友可以加群: 278517979 !!!
另外如果大家觉得文章对你有些作用! 如果想赏钱,可以用微信扫描下面的二维码, 感谢!
另外再次标注博客原地址  xiaorui.cc