Quality Attribute Scenarios（7）：Performance

March 26 09:00~10:38

今天介紹課本82-84頁提到的performance（效能）的內涵。在談到軟體的非功能需求時，performance也是一個經常被提起的因素。評估一個系統的效能牽扯到三個因素：

• Event：事件發生所以系統做了一些事情回應該事件。事件的種類很多，包含interrupt、message、request等等。事件可能如圖一所示的來自於系統外部，或是如圖二所示的來自系統內部。
• Processing resources and time：系統需使用資源與時間來處理事件。
• Response：系統對於事件的反應。在正常情況之下，系統經過一段時間應該回應每一個事件的請求，但是在某些情況，例如系統負載很重的時候，系統可能會被允許只回應若干比例的事件。

 

                         圖一

 

                          圖二

如果今天是開發一個單機版的軟體，事件的來源只有一種，在這種情況之下系統的performance問題就比較容易設計。但是由於實際上很多系統（尤其是網路連線的系統）的事件來源數量（可以簡單想成使用者的數量）、事件到達的模式（arrival pattern）與事件成長的速度不容易預估，因此使得performance問題變得相當複雜。

根據書上的說法，事件到達的模式可分為三種：

• Periodic：週期性的事件，這種事件在所謂的real-time系統中很常見，例如每二十微秒控制引擎的供油量。在一般的商業系統也很常見，例如每七天備份一次資料庫，或是每一分鐘檢查一次有沒有新的電子郵件。
• Stochastic：根據某種機率分布所產生的事件。
• Sporadic：不屬於periodic與stochastic的偶發性事件，講成白話文就是無規則可循的事件產生模式。

 

介紹完事件，接下來談一下系統的反應（response）。根據書上的說法，系統反應可分為以下幾類：

• Latency：系統回應事件所花的時間，有的人叫做response time。
• Deadline：系統必須要在固定的時間內完成處理事件的工作，例如，每個網路封包必須要在二微秒之內被網路交換器處理完畢，這個二微秒就是所謂的deadline。
• Throughput：系統的輸出量，例如一秒鐘之內可以處裡的資料庫交易量。
• Jitter of the response：系統回應事件所花時間的變化程度（the variation in latency）。這一點也很重要，因為如果一個系統的反應時間變異量很大，那麼使用者在使用系統時可能會得到「不好的使用者經驗」。例如，平常完成一筆交易只需要三秒，但是有百分之一的比率，完成一筆相同大小的交易卻需要三分鐘。雖然「平均反應時間」可以滿足使用者的要求，但是這麼大的差異性卻不見得可以被接受。
• Number of events not processed：當系統很忙的時候，允許多少數量的事件沒有被處裡。
• Data lost：當系統很忙的時候，允許多少數量的資料遺失。

***

以上就是performance的內涵，講完收工。

***

友藏內心獨白：長大後才發現，架構師所想的performance和程式設計師所想的performance是不太一樣滴。