一组RTMFP服务器性能对比

最近研发了公司的rtmfp服务器,参考http://blog.csdn.net/win_lin/article/details/38779151,原因是cumulus性能还是不满意。

对比的rtmfp服务器包括:

  • cumulus:这个是老牌的rtmfp服务器,还不错,目前我们线上在跑。
  • rtmplite:这个更老,比cumulus还老,python做的。我们主要参考它来研发我们自己的服务器。
  • bravo-rtmfpd:这个是参考rtmplite,以及一些博客,rtmfp标准协议,我们自己研发的服务器,参考http://blog.csdn.net/win_lin/article/details/38779151。
先测试下其他两个服务器的性能,我们的服务器还没有经过性能优化,所以会测试多次。
工具是我们自己写的,基于st的一个工具,类似于st-load,能模拟10k并发。并且能统计出丢包率,断开率和超时次数,对于分析服务器的服务质量有极大的帮助。
另外,只测量握手和ping包。peer和peer之间打洞不测量,其实这个就是多了两个包而已,没有什么特别的性能开销。

RtmpLite性能测试

测试rtmplite的性能。启动rtmplite的命令是:
python rtmfp.py --no-rtmp

以下是性能数据:
一组RTMFP服务器性能对比_第1张图片
备注:SSp,随机启动休眠时间(秒)。启动时随机休眠,模拟客户端并发。
备注:带宽kbps,内存MB,CPU为top显示的值,丢包率和断开率为百分比。
备注:时长为测试的时间(秒)。
备注:测试为lo网卡,本机127.0.0.1地址

比较有理由相信,rtmplite的并发在500左右。
 超过这个就开始丢包和session超时严重了。 

Cumulus性能测试

测试cumulus性能。启动cumulus的命令是:
cd ~/git/Cumulus/CumulusServer && ./CumulusSer

以下是性能数据:

备注:SSp,随机启动休眠时间(秒)。启动时随机休眠,模拟客户端并发。
备注:带宽kbps,内存MB,CPU为top显示的值,丢包率和断开率为百分比。
备注:时长为测试的时间(秒)。
备注:测试为lo网卡,本机127.0.0.1地址

貌似cumulus是10000并发时开始出现丢包和断开,10k左右是比较合理的数据。CPU因为是ping包,所以占用不多,实际上会有很多p2p握手包,比较费cpu。

BravoRtmfpd在CC后的性能对比

对性能进行对比测试,在没有优化性能之前,先对比一下。CC即代码完成。

以下是性能数据:

一组RTMFP服务器性能对比_第2张图片

备注:SSp,随机启动休眠时间(秒)。启动时随机休眠,模拟客户端并发。
备注:带宽kbps,内存MB,CPU为top显示的值,丢包率和断开率为百分比。
备注:时长为测试的时间(秒)。
备注:测试为lo网卡,本机127.0.0.1地址

可以看到我们支持20k+是没有问题的。

加解密集群性能分析

gprof测试性能,发现时间都被加解密(key计算)占用了。数据如下:

              %   cumulative   self              self     total           
              time   seconds   seconds    calls  ms/call  ms/call  name    
              69.89     45.44    45.44                             bn_sqr4x_mont
              15.86     55.75    10.31                             bn_mul4x_mont_gather5

具体参考http://blog.csdn.net/win_lin/article/details/38779151。

去掉加解密之后,性能数据变为:

                   %   cumulative   self              self     total           
                  time   seconds   seconds    calls   s/call   s/call  name    
                  14.20      2.44     2.44                             heap_delete
                   7.76      3.77     1.33 16640538     0.00     0.00  std::less<unsigned int>::operator() const
                   5.86      4.77     1.01                             heap_insert

可见频繁释放内存有提升的空间,map的比较less已经最优了。

结论就是几点:
1. 加解密集群那块是大头,占80%性能瓶颈。这个可以和rtmfp集群互补。
2. 频繁释放内存是小头,占10%。tcmalloc试了作用不大,可能需要自己管理内存分配,需要用缓存。
3. 可以用rtmfp集群,master管理共享数据,worker去查询。可以和加解密集群配合。
客户端模拟工具最重要,不然无法度量改进效果。

快速Cookie查找

rtmfp在rhello时服务器发送给客户端64字节的cookie,用来标识临时会话,等rikeying之后变成session_id。握手时,cumulus很老实的比较64字节,而我们实际上保证前面8字节是唯一的,也就是u_int64_t整型和64字节cookie对应。

也就是说,cumulus在收到iikeying包时,查找cookie是O(n*n)复杂度的,而我们是O(lg(n)),换句话来说,对于一个4000000个节点时,cumulus每次都要查询4000000次,而我们只需查询32次就可以找到cookie。

class Handshake : public ServerSession {

	struct CompareCookies {
	   bool operator()(const Poco::UInt8* a,const Poco::UInt8* b) const {
		   return std::memcmp(a,b,COOKIE_SIZE)<0;
	   }
	};
	
	std::map<const Poco::UInt8*,Cookie*,CompareCookies> _cookies; // Cookie, in waiting of creation session

我们的数据结构:

class RtmfpHandshake : public IRtmfpPacketHandler
{
private:
    // key: cookie fast id,
    // value: the cookie object.
    std::map<u_int64_t, RtmfpCookie*> cookies;


你可能感兴趣的:(一组RTMFP服务器性能对比)