Linux 下高性能用户空间时间服务

源码获取：svn checkout http://fy2009.googlecode.com/svn/trunk/ fy2009-read-only

高性能，大容量服务器软件多数采用异步工作方式，但该方式却是典型的双刃剑，需要较高设计与实现水平，否则，不仅不能提高性能，反而使软件的复杂性大大增加，可靠性大大降低。本篇不打算对此全面展开去，只就异步模型中最常用的一个基本问题，时间服务，进行稍微深入的探讨。

在异步工作模型中，时间服务总是被频繁的访问，如用于单个任务的执行时间凭估以及各类超时控制等等。高效的时间服务对提高异步服务器软件的性能是重要的。

因异步模型中最大量用到的时间服务是凭估任务的执行时间，通常并不关心具体某个时刻究竟是某年某月某日某时某刻。因此，在Windows操作系统中GetTickCount是最常用到的时间服务函数，而在Linux中，则常用gettimeofday. 测试表明GetTickCount具有非常高的效率，而gettimeofday的表现则不容乐观。两者的测试结果如下：

测试条件：Windows XP 2002--Intel(R) Celeron(R) CPU 2.66GHz

Linux 2.4.18-14--Intel(R) Celeron(R) CPU 2.00GHz

基准测试一：测试1千万次累加操作的执行时间

long ll=0;

for(int i=0;i<10000000;++i) ++ll;

测试结果：Windows:31ms; Linux: 30ms

两者非常接近

基准测试二：测试1千万次简单函数调用的执行时间

class CA{

public:
inline int get_tick() { return _tc; }
private:
int _tc;
};

main()
{

CA a;
for(int i=0;i<10000000;++i) ll=a.get_tick();

}

测试结果：Windows:404ms; Linux: 80ms

目标测试：测试Windows下调用GetTickCount和Linux下调用gettimeofday各1千万次
测试结果：Windows: 128ms; Linux: 6709ms
结论：Windows下GetTickCount具有非常高的性能（甚至比一个最简单的函数调用还要高效，有些不可思议），你尽可以“想调就调”，不必太担心其可能带来的性能损害，但在Linux下情形就很不相同了，gettimeofday的性能与GetTickCount有着天壤之别（按Linux世界的规则可解释为gettimeofday是系统调用，需要进入“系统空间”，因此需要进行开销较大的Context Switch，但不知GetTickCount为什么可以做到高效得让人生疑）。

目标测试：Windows下测试1000万次::QueryPerformanceCounter调用
测试结果：18000ms

结论：该函数在Windows上具有最高的计时精度，但天下没免费的午餐，高精度的代价就是低效率，和GetTickCount比，其性能可以用“惨不忍睹”来描述，所以，对待计时精度的态度应该是够用就好，盲目追求高精度，往往代价惨重。结合本开源项目的实际需要，GetTickCount是我当然的选择。

实现高效的时间服务
不管出于什么原因，为Linux下工作于异步模式的软件提供一个高效的时间服务都是有必要的，好在这在一定程度上是可行的。本项目中的user_clock_t将在Linux下提供这样的服务（在Windows下它则显得多余），其基本原理是利用一个独立线程定时累加计数器，并周期性调用gettimeofday校准该计数器，该计数器的当前值即被用作当前时间戳，因具体的时间服务并不涉及系统调用，因此，效率非常高，缺点是精度有限，在上述测试环境中，最高精度只能达到3ms左右，而10ms精度则是有保障的。好在异步模型中，通常对时间精度的要求不太苛刻，10ms精度通常可以满足要求。如你有足够的理由说10ms精度不能满足，则你仍得直接调用gettimeofday, 但你在这么做之前应该三思：你是否真得有必要这样做？