高效的系統開發要領(2)找出最關鍵的效能瓶頸

在正式的開發動作啟動之前，通常即會針對預期系統該有的效能訂定目標，也在兼顧實際所需彈性的情況下，盡可能地朝向高效能的架構設計。

我們更盡可能地在技術方案（程式語言、程式庫、編譯器、……）選擇的決策過程裡，在滿足現實的限制條件時，挑選其中成效較高者，而且更進一步透過開發流程中的程式碼審閱活動，提早發現埋藏在系統幽暗處的效能地雷。然而，系統終於能夠運行時，不見得能夠一次到位，滿足原先所設定的效能目標。

效能測試與壓力測試
一般來說，在測試階段的後期，許多專案都會針對自行所開發的系統，執行所謂的效能測試（Performance Testing）。效能測試的目的，是為了測試在不同程度的負載（load）下，系統在效能上的反應如何。當我們在測試時「餵」給系統極高的壓力時，這種效能測試，也就變成了壓力測試（Stress Testing）。壓力測試時常用來檢驗在極限的負載下，系統的效能表現、穩定度、異常錯誤的處理能力。

市面上目前可以找到許多用來執行效能測試或壓力測試的工具，但是，針對不同類型的應用系統，會需要用到對應類型的工具。例如，針對Web-based的應用程式，須搭配專門的Web應用程式的測試工具。

效能測試工具的最大用途，在於為你產生所想要的負載。利用測試工具產生龐大的同時線上人數的負載，是利用測試人員的人工所難以達到的。此外，效能測試工具多半搭配效能量測工具一併使用，除了為你產生所需的效能負載之外，同時利用量測的工具，為你記錄系統的效能表現。有了這兩種工具，一方面可以調整要餵給系統的負載，一方面又可以記錄系統在該負載下的效能行為及表現。了解系統在不同程度的負載下的效能表現，除了增加自知之明外，最大的作用就是利於後續的效能調校（Performance Tuning）工作。

有些系統是在正式上線或發行之後，遭遇到效能的問題時，才回過頭來診斷效能瓶頸。但專案時期倘若能執行效能測試或壓力測試，比較有機會提前在未上線前或發行之前，發掘出效能的問題，進而著手解決。

你可以尋找現成的效能測試、量測工具，也可以自己著手開發自用。然而，考慮現成的方案會比較務實些，畢竟生產力是最關鍵的因素之一。現成、開放原始碼的測試工具是不少，而封閉性質的商用測試工具又多半昂貴，如果有經濟因素的考量，採用開放原始碼的工具，多半是較佳的選擇。

待工具備齊，效能測試與效能調校的工作便可以開展。

找到執行時間最長之處，改善它！
許多人在從事效能調校的工作時，最大的盲點在於沒有重心地調整。所謂沒有重心地調整，便是地毯式地嘗試提升系統每一塊的效能，但這麼做是十分浪費力氣的。有一個很有名的法則叫做Amdahl’s Law。這個法則告訴我們，倘若我們用時間來做為評估效能的指標時，那麼

系統改進後的執行時間＝
（被改善部分的執行時間／改善倍數）＋
未被改善部分的執行時間

Amdahl's Law背後的意義就是，倘若你要提升效能，最有效益的方式，便是直接改善執行時間最長的那個部分，因為針對這去調整，可以提供對系統整體最多的改善。

例如，有一個系統執行一個動作，可分解為A、B、C三個子動作，總共需要100秒，其中A就足足就需要60秒，B需要20秒、C也需要20秒。如果針對B改善，就算有10倍的改善效果，也只不過將B的執行時間降到2秒，整體系統的總執行時間仍達82秒。但如果針對A改善，即使只有兩倍的效果，讓A部份降低到30秒的時間，整體系統的總執行時間，就降到了70秒。如果能做到三倍的改善效果，總執行時間更可降到60秒。A這個部分就是系統效能的瓶頸（bottleneck）所在，它正是影響系統效能的最關鍵部份，倘若要著手改善，拿它開刀，經濟成本最佳。

這正是許多人調整效能時常常忽略的。許多人一遇到系統效能不佳，也不試著去找出系統真正的瓶頸所在，只像隻無頭蒼蠅，胡亂找地方調整，試著提升自己所能見到的每一處程式碼的效能。

並不是說這些調整一點效果都沒有，而是說，倘若調整處並非系統的瓶頸所在，那麼所做的調整，時常就只有些微的提升，對系統整體的改善幅度並不大。Amdahl's Law已經告訴我們，直接切入關鍵的瓶頸處，加以改善提升，能得到最大的效益。

搭配工具審閱程式碼，較有效率
這正是我們需要效能量測工具的主因，透過它，我們可以分析系統運行的主要執行路徑（Execution Path），找出熱門而且執行時間最長的部份，也就是系統效能的瓶頸。倘若沒有進行定量的分析，只是一味瞎猜，很難具體找到實際的瓶頸，這麼一來，就找不到最關鍵的切入點了。

效能調校多半可以這麼簡單的看待：

步驟1：產生所需的系統負載
步驟2：進行效能量測
步驟3：找出效能瓶頸
步驟4：針對效能瓶頸進行改善
步驟5：回到步驟1，重複這個程序，直到沒有明顯的效能瓶頸為止

當我們找出了效能瓶頸後，便可以著手改善。不同的瓶頸，所導因的問題也不盡相同，因此也必然會需要用不同的方式去解決。找出瓶頸有相當重要的意義，因為這代表著我們知道應該要將目光放到系統的那一處。

在開發階段，儘管我們會做程式碼審閱，但不見得可以很容易地預先知道那一段程式碼是需要付出額外的關心。但是，當我們在做完效能量測，便可以知道，那一段程式碼需要被放在聚光燈下更詳細的檢視。在試著努力改善程式碼後，我們可以再次利用效能量測工具，評估所做的改進對瓶頸帶來的提升。倘若沒有效果，代表改善的方式不對，需要再擬定新的改進方案。倘若有了效果，但未達目標，除了再投入新的改進方案外，也需要考慮將重心移至次要瓶頸了。

改善次要瓶頸也有一定成效
我們有機會透過效能提升的手段，將瓶頸消除。也就是說，原先占據最多執行時間的部份，因為效能的改善，不再是系統中花費最多執行時間的部份。此時，系統的次要瓶頸便會浮現，搖身一變成為主要的瓶頸。

可惜的是，並非所有的主要瓶頸，我們都能找到足夠好的效能提升方案予以消除、化解，有很多時候，我們只能將主要瓶頸的效能提升到某一個程度，就停滯不前，但主要瓶頸仍舊是主要瓶頸。在這種情況下，只能將目標轉移到次要的瓶頸，因為主要瓶頸已無明顯可著力之處。

總的來說，我們在調校效能時，會依循上述的一般性步驟來進行：找出瓶頸、改善瓶頸、重新評估瓶頸、……，反覆直至達成系統效能目標為止。但是，不同的效能瓶頸會有不同的改善方式。在下一回中，我們會介紹一些常見的效能問題，以及如何加以改善。

《作者簡介》王建興
清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。

相關閱讀：
高效的系統開發要領(1)制定量化效能目標，作為調整基準
高效的系統開發要領(3)當瓶頸在運算量時，先從程式下手
高效的系統開發要領(4)當瓶頸在檔案存取時，善用快取
高效的系統開發要領(5)努力瘦身，輕鬆通過對外頻寬的瓶頸
高效的系統開發要領(6)伺服器運用頁面快取，加速效果驚人
高效的系統開發要領(7)把關資料處理細節，效能過關很簡單