提高WEB服务响应时间by优化日志打印

发布时间:2014-10-23 23:31:07
来源:分享查询网

    原文URL: http://blog.csdn.net/u012859646/article/details/16840301 [2012.3]     服务器端的开发优化(不考虑前端优化因素),相信了解的人都可以说出点道道来。优化,其实有很多的衡量标准,仅从服务器端来说,至少可以有并发度,相应时间,处理时间,吞吐率,服务器负载等等,而且这些因素有时也相互作用,提高某一个指标,其它指标可能下降。例如,你减少了一个请求的处理时间(引入更复杂耗CPU的算法),那么机器的负载可能上升,而吞吐率就反而下降。还可以从用户体验和服务器的方面来分类,就是一个优化是让用户感觉更快(页面打开),还是让机器处理得更多更快。这些因素并不等同,所以,优化是一个需要多方权衡的过程。          本文讲的无非是一个小TIP,随想随记的东西而已,也没有什么数据或实验,顶多算个“技术散文”。难免“形散神散”之嫌,所以大家也就将就看看就是。          服务器端的开发,打日志总是免不了。常规的作法就是将日志记在本地文件系统。这自然要写文件,写文件就会涉及文件IO,而IO操作又是一个很慢的过程,因此你打的日志多多少少得耗去些时间。特别对于刚上线的服务,常常会把日志开到DEBUG级别,一个请求10条日志都不鲜见,于是,全部打日志的时间得花去几毫秒甚至到几十毫秒。在内存不足,压力较大的条件下,这个情况状还会恶化。举个WEBserver的一般工作流程。极简化版本如下        parseRequest(); LogSomething0(); requestBackServer1(); LogSomething1(); requestBackServer2(); LogSomething2(); renderPage(); LogSomething3(); displayPage(); LogSomething4();       这是一个WEB服务的处理流程,如果是一个业务逻辑模块,差别不大,不过parseRequest 处理的是请求包,而displayPage换成向请求的client发送应答包即可。先不考虑实际业务的处理时间,客户端能得到响应至少也需要等待4条日志的打印时间。          假如我们记一个请求的处理时间为M,而客户端等待响应的时间为N。不考虑网络传输时间的情下, M>=N。我们从客户端的用户体验来考虑,自然希望这个N尽量的小,这样用户“感觉”起来就更快。           为此,我们可以考虑,将所的日志IO延后,即让其发生在客户端得到响应之后。上面的例子,我们完全可以在 dispayPage 后再来考虑打日志。这样,就将日志IO的时间消耗从原来的N中去掉一部分。         之前的LogSomething[0-3]呢?只需要优化下实现,在函数里简单地“记而不打”(就是不输出到文件中)。详细道来,只需把每次日志的内容以字符串的形式记录到一个队列(内存中)即可。在响应完成后,一次将全部个日志输出到文件(这样理论上还能提高IO效率)。对于支持OOP的语言,可以考虑将最后打日志这个操作放到某个对象的析构函数里,连在最后一步显式调用的Log函数都省去。      以上,一个小TIP差不多讲完了。它优化的对象不是处理时间,而是响应时间,从而给用户带来“更快”的体验。用脚本语言实现这么个LOG库是极简单的,效果也是可以期待的。           最后一个问题,也许有人用c/c++之类的语言开发服务,在日志打印出来前可能因为严重错误导致coredump,在原来方式,也许(只能说也许),可以从文件日志中看出点端倪来,但现在可能没有了。解决方案,是可以把未输出的信息,放在全局buffer里,只要这个全局变量不被写坏,通过神器GDB还是能从coredump中查看遗留下来的日志。   2012.3 --EnD--

返回顶部
查看电脑版