最近设计了一个网络服务器程序,对于4C8G的机器配置,TPS可以达到5W。业务处理逻辑是简单的字符串处理。服务器接收请求后对下游进行类似广播的发送。在此分享一下设计方式,如果有改进思路欢迎大家交流分享。
程序运行在CentOS7.9操作系统上,GCC使用4.8.5版本,网络是千兆网。
接收流程
展示如下:
epollin进来之后会进行会话组的读锁锁定,这样会话不可能在上锁期间析构掉,保证了会话指针(包括其内部的接收缓存)的安全。在会话处理内部对消息缓冲区进行了尝试上锁。如果上锁失败则返回(这样保证了如果一个会话的数据特别多,其他网络接收线程也可以及时处理其他会话进来的数据)。
发送流程
如下:
发送线程有两种模式:直接发送、缓冲发送。直接发送模式就是直接将需要发送的数据发送处理,缓冲发送是将数据写到会话的缓冲区,然后进行发送。直接发送的好处就是可以不用复制数据,这样可以减少CPU和内存的占用,但是坏处就是由于没有对于每个会话进行单独的缓冲,因此需要遍历每个会话,对数据进行依次发送。此时,如果有一个会话的接收速度特别慢,就会导致整体的发送效率降低。缓冲发送模式则不存在这个问题,一个会话的接收速度慢,但是它有自己的缓冲区,所以可以直接把数据复制到它的缓冲区中,然后继续下一个会话的发送。
系统使用优先直接发送,如果遇到EAGAIN时候直接转到缓冲区发送的方式。这样就可以保证尽量不复制缓冲区,同时在发送遇到阻塞时候也能不影响其他会话。
效果测试
在5W的TPS下可以接收8个下游系统,上下游网络流量已经几乎达到带宽极值,CPU占用率67%,内存在运行48小时后会达到78M。
但是还是存在问题。1)单独使用缓存发送模式的时候有一个问题,就是CPU占用率特别高,每多一个会话则CPU的占用率升值需要升高10%-20%(这里似乎没有CAS导致的CPU占用,同时,使用的锁也全都是普通锁,并没有自旋锁);2)下游接收速度很慢的时候CPU占用率会提高到70%以上。