C++ 后台程序实时性能监控

面对的问题:

做后台程序经常会被问一句话,你的程序能撑多少人。一般官方一点的回答是这个得根据实际情况而定。实际上后台程序的性能是可以被量化的。我们开发的每一个服务器程序,对性能都非常有底,以为我们有数据。So,能撑多少人不少随便猜的,让数据报表来说话。

另外一种情况经常发生在开发人员之中,甲乙丙一起讨论接口实现,经常会说这么实现效率太低,那么实现效率才高等。实际上,效率高低都是相对而言的。一个函数1ms执行完毕够快吗?看起来挺快,若某接口需要此函数100次循环,那么情况就不是很乐观了。但是若此接口又是十天半个月才会被触发一次,似乎事情又变的不是很严重。说到这里想起《unix编程艺术》上关于性能优化的总结:

  • 最有效的优化往往是优化之外的,如清晰干净的设计
  • 最有效的优化就是不优化,摩尔定律会为你优化
  • 如果确定要优化,必须找到真正的瓶颈

还有一种跟性能有关的情况是,后台程序经常有很多组件组成。比如在运行期发生接口调用性能下降的情况,必须知道是那些组件性能下降引起的。如果可以实时的知道所有接口的性能数据,以上的问题都可迎刃而解。

总结如下原因,必须开启实时性能监控:

  • 我们需要知道系统的吞吐量,以此参数做部署等。
  • 实时了解各个系统组件的性能,某组件发生故障,可以及时发现
  • 获得程序接口调用热点,调用多且慢的接口才需要优化

解决方案:

后台程序开发一个专门统计性能的组件,其需要有如下功能:

  • 可以汇总性能数据,如定时将1小时内说有接口调用开销、次数等数据汇总到文件
  • 可以非常方便的与逻辑层接口集成,比如在现有接口增加一行代码即可
  • 直观的报表,性能数据写入文件必须按照通用的格式,方便工具分析数据,生成报表

性能监控组件

我实现了一个性能组件performance_daemon_t。接口如下:

//! 性能监控
class performance_daemon_t
{
public:
    struct perf_tool_t
    {
        perf_tool_t(const char* mod_):
            mod(mod_)
        {
            gettimeofday(&tm, NULL);
        }
        ~perf_tool_t()
        {
            struct timeval now;
            gettimeofday(&now, NULL);
            long cost = (now.tv_sec - tm.tv_sec)*1000000 + (now.tv_usec - tm.tv_usec);
            singleton_t<performance_daemon_t>::instance().post(mod, cost);
        }
        const char*    mod;
        struct timeval tm;
    };
public:
    performance_daemon_t();
    ~performance_daemon_t();

    //! 启动线程,创建文件
    int start(const string& path_, int seconds_);
    //! 关闭线程
    int stop();

    //! 增加性能监控数据
    void post(const string& mod_, long us);

perf_tool_t 是工具类,构造和析构自动调用两次gettimeofday获取函数调用开销,例外有辅助宏定义如下:

#define AUTO_PERF() performance_daemon_t::perf_tool_t __tmp__(__FUNCTION__)

#define PERF(m)     performance_daemon_t::perf_tool_t __tmp__(m)

使用示例:

void foo()
{
    AUTO_PERF();
    //! TODO -----
}

int main(int argc, char* argv[])
{
    
    singleton_t<performance_daemon_t>::instance().start("perf.txt", 5); 
    foo();
}

performance_daemon_t 每隔5秒将性能统计数据输出到perf.txt, perf.txt的内容是CVS文件格式。

报表工具:

perf.txt 文件内容还不够直观,示例内容如下:

time,mod,max_cost[us],min_cost[us],per_cost[us],request_per_second,exe_times
20120606-17:01:41,dumy,515,174,254,3937,390
20120606-17:01:41,foo,5924,4,506,1976,1030
20120606-17:01:41,test,304,8,243,4115,185
time,mod,max_cost[us],min_cost[us],per_cost[us],request_per_second,exe_times
20120606-17:11:41,dumy,1086,222,280,5571,312
20120606-17:11:41,foo,5707,194,503,1988,770
20120606-17:11:41,test,807,8,265,3773,142
time,mod,max_cost[us],min_cost[us],per_cost[us],request_per_second,exe_times
20120606-17:21:41,dumy,1086,222,680,2571,512
20120606-17:21:41,foo,5707,194,403,1388,470
20120606-17:21:41,test,807,8,265,4773,442

为生成足够友好、直观的报表,我实现了一个WEB报表页面,http://ffown.sinaapp.com/perf/, 将perf.txt 内容直接粘贴到web 页面,点击转换输出如下报表:

各个接口性能监控-折线图:

此图显示了三个接口随时间顺序的走势,可以非常清楚foo、test、dumy三个接口那个时间性能高,哪个时间性能低,一目了然。

接口热点分布图:

显示三个接口随时间调用次数走势,可以很清楚显示哪个时间段是高峰期。大饼图显示了哪个接口是热点接口,很明显,foo 接口调用次数最多,优化当优先优化foo。

组件实现浅析:

post 接口:

程序把接口调用开销投递到性能组件任务队列中,保证了对接口性能影响最小。

timer定时回调:

timer_service_t 是我用epoll 实现的定时器,主要实现如下:

void timer_service_t::run()
{
    struct epoll_event ev_set[64];
    //! interupt();

    struct timeval tv;

    do
    {
        ::epoll_wait(m_efd, ev_set, 64, m_min_timeout);

        if (false == m_runing)//! cancel
        {
            break;
        }

        gettimeofday(&tv, NULL);
        long cur_ms = tv.tv_sec*1000 + tv.tv_usec / 1000;

        process_timer_callback(cur_ms);
        
    }while (true) ;
}

process_timer_callback 中检测链表内所有的定时任务,若超时,触发回调函数。

备注:

有人可能当心AUTO_PERF(); 会影响接口性能,其实其平均开销大约为1us 

代码实现:

https://ffown.googlecode.com/svn/trunk/example/ff_performance

WEB 报表生成工具:

http://ffown.sinaapp.com/perf/

 文档:

http://ffown.sinaapp.com/perf/perf.pdf

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏沈唁志

API接口开发简述示例

1442
来自专栏欧阳大哥的轮子

论MVVM伪框架结构和MVC中M的实现机制

一直都有人撰文吹捧MVVM应用开发框架,文章把MVVM说的天花乱坠并且批评包括iOS和android所用的MVC经典框架。这篇文章就是想给那些捧臭脚的人们泼泼冷...

713
来自专栏守候书阁

重构 - 改善代码的各方面问题

做前端开发有一段时间了,在这段时间里面,对于自己的要求,不仅仅是项目能完成,功能正常使用这一层面上。还尽力的研究怎么写出优雅的代码,性能更好,维护性更强的代码,...

40513
来自专栏Java Edge

Redis Cluster流程原理

Redis 3.0之后,节点之间通过去中心化的方式,提供了完整的sharding、replication(复制机制仍使用原有机制,并且具备感知主备的能力)、fa...

622
来自专栏架构之路

高并发请求的缓存设计策略

前几天,我司出了个篓子。当时正值某喜闻乐见的关键比赛结束,一堆人打开我司app准备看点东西,结果从来没有感受到过这么多关注量的该功能瞬间幸福到眩晕,触发了熔断,...

762
来自专栏即时通讯技术

网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

本文原作者:“水晶虾饺”,原文由“玉刚说”写作平台提供写作赞助,原文版权归“玉刚说”微信公众号所有,即时通讯网收录时有改动。

672
来自专栏高性能服务器开发

(八)高性能服务器架构设计总结1——以flamigo服务器代码为例

这篇文章算是对这个系列的一个系统性地总结。我们将介绍服务器的开发,并从多个方面探究如何开发一款高性能高并发的服务器程序。

822
来自专栏微服务生态

利用多写Redis实现分布式锁原理与实现分析

在我写这篇文章的时候,其实我还是挺纠结的,因为我这个方案本身也是雕虫小技拿出来显眼肯定会被贻笑大方,但是我最终还是拿出来与大家分享,我本着学习的态度和精神,希望...

813
来自专栏曾令武的专栏

消息队列及常见消息队列介绍

消息队列是分布式系统中重要的组件,在很多生产环境如商品抢购等需要控制并发量的场景下都需要用到。最近组内需要做流水server的选型升级,这里对消息队列及常见的消...

5.1K4
来自专栏Golang语言社区

Go 语言构建高并发分布式系统实践

你知道互联网最抢手的技术人才有哪些吗?最新互联网职场生态报告显示,最抢手的十大互联网技术人才排名中Go语言开发人员位居第三,从中不难见得,Go语言的渗透率越来越...

4815

扫描关注云+社区