[設計原則] 爲模塊設計統計信息

     設計的過程能夠存在依靠感受去把握，可是最終軟件產品哪一個地方存在不足，或者在用戶那運行的狀態如何，乃至一種錯誤的出現其根源是什麼等等，就不能徹底依靠感受去行事了。對於這些問題的分析是須要思考，但最終哪種思考是正確的或更具可能性卻須要讓數據來講話，爲模塊設計統計信息的目的就在於此。

     現實世界的複雜也反映在了軟件的設計上，軟件在開發過程當中並不可能徹底掌握軟件產品在客戶手中運行時的全部環境細節或用戶使用習慣，在設計過程當中碰到這類問題的決擇一般是很痛苦的，由於它不是一個簡單的二選一問題，每每有可能在不一樣的用戶手中，表現爲二者最終都對。考慮軟件對用戶環境的適應能力，一般須要爲軟件提供必定的配置手段。如何決定哪種配置更適合用戶環境呢？經過問用戶？是的，對於那些與可以使用性（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

     一個軟件系統應當設計哪些統計信息呢？這能夠經過思考哪些信息在軟件產品出現異常時將有助於分析問題，只要對於分析問題有用就能夠考慮增長相應的統計項。設計統計項並不要求一步到位，能夠在軟件生命週期的任何階段增長統計項，只要以爲它的增長是有意義的就好了。

     最後，模塊是軟件系統的組織單位，而將統計信息設計成以模塊爲單位就顯得很天然了。