[设计原则] 为模块设计统计信息

     设计的过程能够存在依靠感受去把握，可是最终软件产品哪一个地方存在不足，或者在用户那运行的状态如何，乃至一种错误的出现其根源是什么等等，就不能彻底依靠感受去行事了。对于这些问题的分析是须要思考，但最终哪种思考是正确的或更具可能性却须要让数据来讲话，为模块设计统计信息的目的就在于此。

     现实世界的复杂也反映在了软件的设计上，软件在开发过程当中并不可能彻底掌握软件产品在客户手中运行时的全部环境细节或用户使用习惯，在设计过程当中碰到这类问题的决择一般是很痛苦的，由于它不是一个简单的二选一问题，每每有可能在不一样的用户手中，表现为二者最终都对。考虑软件对用户环境的适应能力，一般须要为软件提供必定的配置手段。如何决定哪种配置更适合用户环境呢？经过问用户？是的，对于那些与可以使用性（usability）相关的主题，询问用户每每很容易获得答案，由于用户将告知他使用软件的感觉。可是，对于那些用户看不见也摸不着的内容，经过询问用户的方式就会使他茫然，也别期望获得想要的答案。对于这类问题只能问咱们所设计的软件，可软件又不会说话!而经过设计统计信息的方式可让软件“说话”。有了统计信息的设计之后，软件产品可让用户先使用一段时间以收集统计信息。对于常常须要重启的软件，能够考虑在软件退出时写日志的方式保留此次的统计信息，对于电信级产品因为其并不常常重启，则能够考虑采用按期输出日志的形式获取统计信息，或者向用户提供命令行的方式以备须要时查询这些信息。有了用户现场的统计信息之后，就能够帮助分析现有软件应当作怎样的调整，可能有的只须要更改用户配置，也可能有的须要在下一个版本中考虑进行设计更改，等等。

     前面谈到的统计信息的做用更多的是从系统调优的角度，使系统更易于使用或资源的配置更加的合理，统计信息另外一个比较重要的用处是帮助分析软件异常。若是一个软件产品是从外部接受消息并对之进行处理和响应的，当某些情形下出现软件系统的负荷异常高时，假设存在统计信息以记录进入系统的消息，那么经过这一统计信息就能够判断是不是由于进入系统的消息异常的多而致使负荷异常的高。另外，有时模块出现错误时并不能采用直接写日志的方式，不然可能产生性能问题。好比内存管理模块出现内存不足没法完成内存分配时，最好的方式不是直接在内存管理模块内写错误日志，而应当是返回空指针给调用者，至因而否输出日志应彻底由调用者去决定，由调用者去输出日志的好处是其所输出的日志一般更加的全面。可是，内存管理模块能够考虑设计统计信息，在每一次没法完成分配时就对相应统计项进行更新。这些信息的存在为须要时提供更多的分析数据，大多难于定位问题的软件缺陷正是由于“蛛丝马迹” 太少。

     统计信息一般采用为每个统计项定义一个×××变量的形式，图1是一个定时器模块所设计的相关统计信息。从29和48行能够看出statistic_t就是整型的typedef。70、71以及78~80行则定义了相应的统计变量。当相应的情形出现时，好比定时器不足的情形下，则对相应的统计相进行加一操做，在这里将对notimer_统计变量进行加一操做。而显示统计信息就是将这些统计变量的值进行输出使之可读。由此看来，增长统计信息的成本不管是内存、仍是处理器时间都是很小的。

os/source/common/inc/primitive.h

00029: typedef unsigned int u32_t;

00047: // for statistic

00048: typedef u32_t statistic_t;

os/source/timer/v3/src/timer.c

00067: typedef struct

00068: {

00069: dll_t dll_;

00070: statistic_t hit_;

00071: statistic_t redo_;

00072: csize_t reentrance_;

00073: csize_t level_;

00074: } bucket_t;

00075:

00076: typedef struct

00077: {

00078: statistic_t notimer_;

00079: statistic_t traversed_;

00080: statistic_t abnormal_;

00081: } timer_statistic_t;

00082:

00088: static bucket_t g_buckets [MAX_BUCKETS];

00089: static timer_statistic_t g_statistic;

图1

     一个软件系统应当设计哪些统计信息呢？这能够经过思考哪些信息在软件产品出现异常时将有助于分析问题，只要对于分析问题有用就能够考虑增长相应的统计项。设计统计项并不要求一步到位，能够在软件生命周期的任何阶段增长统计项，只要以为它的增长是有意义的就好了。

     最后，模块是软件系统的组织单位，而将统计信息设计成以模块为单位就显得很天然了。