l

2012年3月29日 星期四

Quality Attribute Scenarios(7):Performance

March 26 09:00~10:38

image

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

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

 

image

                         圖一

 

image

                          圖二

如果今天是開發一個單機版的軟體,事件的來源只有一種,在這種情況之下系統的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是不太一樣滴。

沒有留言:

張貼留言