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

    原文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--