效能瓶頸下的選擇傾向

約是在 2014 年前後,我想通了一件事,但一直遲未將想法化為文字。今天終於静下心來作這件事了,我想要說明的是,為何在某些效能瓶頸的關頭,我會主張作深度分析優化,而非立即性擴充資源緩解眼前的問題。

舉電商網站經營為例,資料量主要有會員、訂單、商品等資料,大致可初估資料的複雜度以 n^3 的速度在膨脹,因此所需的運算需求量也以這速度跟著成長。這可用下方這示意圖來表示:

View post on imgur.com

//s.imgur.com/min/embed.js

其中X軸為資料量,Y軸為硬體運算量,而運算資源需求則是原點連往A、B、C三點的這條曲線。

當網站逐漸成長,終於來到第一個效能瓶頸點(A) 時,網站又慢又卡、硬體滿載,並已危及正常運作的時候。我們有2個方向的選擇:

《方案一》直接擴充硬體。這可能馬上就解決了(假設是 1 天),相對而言較快速而簡單。

《方案二》分析軟體程式,找出並修正潛在的程式瓶頸。這工程相對耗時長,可能要耗上不少時間(假設是 5-14天),也會有相應的開發成本支出。

因為網站瓶頸會影響營業收入,所以在規避損失的心態下[1],多數人會選擇 《方案一》的路線,直接將資源從 L1 提升到 L2 ,以盡快脫離眼前損失的狀態。接下來發展的狀況大致如下:

1. 很快就擱置了改善軟體效率的念頭 
    A. 因為眼前壓力解除了 
    B. 有其他更重要的事 ( 應付眼前業務、新功能開發、...)·
    C. 非受迫性的額外支出 ( 需要另外撥出預算跟時間 )  

2. 資料量隨時間持續成長,然後又遇到新的瓶頸點 

3. 在瓶頸點再度面臨兩個選擇,但基於 
    A. 業務量較先前更大,相同時間的代價損失並上一次更高
    B. 營運壓力更大,工作人員比先前更加心有餘而力不足 
    C. 先規避眼前立即的損失再說

4. 再度選擇《方案一》,然後重複回到 1. 

最後反覆重覆上述流程,直到獲利跟時間餘裕都被最後吃光,再無法越過某個天花板為止。

那麼,若是一開始在 A 點時,選擇《方案二》的路線會是如何?

從圖中簡單的估計一下 A-P-Q-R 的路線,(假設資料量以每個月 1W 的速度成長),雖然一開始多花了 15 天的時間,但遇到資源關卡 L2 的時間(瓶頸點R) 可能約是 5.5 個月之後。相較之下, A-B-C 的路線,一開始只花 1 天,但可能約 2.5 個月就抵達資源關卡 L2 (瓶頸點B),然後不到 2.5 個月,就抵達資源關卡 L3 (瓶頸點C)。

於是,同樣過了 6 個月的時間,面對相同的資料量,兩者不管是在資源耗用度,或是在時間餘裕度上,都形成了此消彼長的差距。而這差異,其實早在第一個瓶頸點 (A) 當下的選擇就決定了。

最早我以為,有很大的可能,會在 A-B-C 的過程中,轉變另一個選擇。但是,當我不只一次遇到,已經發展到 C 狀態的苦主們,在討論解法時仍不死心的一再追問說

Leave a Reply

Your email address will not be published. Required fields are marked *