《C后台程序实时性能监控.docVIP

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_tperformance_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_tperformance_daemon_t::instance().start(perf.txt, 5); foo(); } performance_daemon_t 每隔5秒将性能统计数据输出到perf.txt， perf.txt的内容是CVS文件格式。 报表工具： perf.txt