Gadget

目前仍無法透過加密連線存取這項內容。

Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2011年3月3日

從電腦效能瓶頸看問題核心

以前在維護網站的時代,採用 UNIX 系統,就特別針對效能瓶頸多加注意。當時遇上龐大的網站瀏覽需求以及網站服務使用需求,使得網站回應相當慢。老闆當然要求要盡快解決,也問過我是不是要換更好的機器,他再去找經費。

但是錢要花在刀口上,因為我們沒有無限的經費。當時的例子,效能瓶頸可能出現在下面幾個點:

  • 網路
    • WAN 還是 LAN ?
    • 設備:是否既有網路設備不足以應付龐大的 session 或是流量,網卡要換還是 Switch / Router 要換?Layer 2 / Layer 4 Load Balance Switch 有沒有效?
  • CPU
    • 網站服務回應慢時,是否 CPU 呈現滿載狀況?
    • 若 CPU 呈現滿載,是哪些程序佔用多數的 CPU 運算效能?
      • 是 httpd 佔用較多效能?
      • 還是網站程式佔用較多效能?
      • 還是其他相關程式例如資料庫佔用較多效能?
  • 硬碟 I/O
    • 硬碟 I/O 是否滿載?
諸如此類,每個不同的環節都可能導致前端服務回應緩慢,解決方法也大大迥異。而往往真實狀況混雜著多種不同背景下產生類似的結果,例如當時某些特定族群的用戶,他們的對外網路頻寬本來就不太夠,多人同時使用時,瓶頸在於他們的對外頻寬;然而相近時間點,其他族群的使用者,網路頻寬都不是問題,那時真正的瓶頸在於伺服器端過載。

解法其實也很多元,除了一方面提升網路品質(即便這後來經證實不是主要瓶頸),一方面從硬體下手改善 CPU 運算以及採用更能應付多工運算的伺服器,硬碟也採高轉速、快速存取的高階硬碟陣列,另一方面也要從軟體下手,改進程式實作方式與檔案系統架構,減低不必要的 I/O 存取,善加利用記憶體暫存,還有把伺服器拆分成多個階層,外加採用多組伺服器做 Load Balance 。

其實改動了這麼多可能因素,一般而言,可能反而不太容易看到是否「錢花在刀口上」。不過當時因為多個環節處於先天不良的狀況之下,同時改善是必要的。

生活上的問題也可以試試採用類似方法加以分析,比方說一家餐飲店為什麼生意不好?
  • 地點因素?
  • 人員因素?
  • 硬體設備因素?
  • 餐點種類?
  • 價格因素?
  • 美味因素?
  • 大環境因素?

0 Comments: