效能調校

January 27th, 2008

搞軟體的常常遇到的問題就是,程式寫好之後,客戶嫌它跑的慢,所以不爽付錢。爽,是一件很重要的事情,所以師程工多半都會被要求無論如何要調到客戶爽為止。不過說真的,效能調校是件很有趣的事情,小弟來分享一些曾遇過的趣事好了。

關於時間方面的效能調校大致上可以分成兩種:縮短執行的時間,或是縮短等待的時間。前者多半出現在後台用的程式,例如小弟以前做過的某個銀行專案,一個批次跑下來要十九個半小時,基本上這等於叫客戶不要開門做生意 🙂 經過一個多月的調校,批次執行時間變成十九分鐘。這麼歡樂的情形也許不常見,不過我倒是從中學到不少有趣的東西:

  • 資料庫的 table design 非常重要,我所做過大部份的專案都是以客戶現有的資料結構下去設計,但客戶的資料結構往往不符合效能最佳化的需求。在一開始設計時就應找出最常用或最關鍵的 query path,針對這個 path 下去設計才對。
  • Stored procedure 的設計必須把握「先細篩後粗篩」的原則,cursor 指向的 data set 越小,跑起來越快。像上面的例子中,我只是把兩個 select 的順序換一下,時間就從十九個半小時變成六小時。
  • 注意一下 team member 的實際能力,雖然這有些傷感情或 micro-management 的嫌疑,不過卻太常見了。一個很有效的鑑別方式是和你的隊友聊天,看看他打算用什麼方法解決問題,若是沒有方法,或是方法的執行上實在不怎麼樣,那就該想想 plan B 了。
  • 擴充性迷思:客戶通常會要求高於他們業務量所需的規格以備未來的擴充,或是要求要有種種神奇的擴充能力。如何委婉的讓他們知道有多少錢玩多大的車是很重要的事情,很多時候系統只打算用五年卻做了十年的規劃,這樣做起來累驗收也累,爽的只有 sales。
  • 注意客戶的真實需求:很多時候程式跑的慢並不是技術上有問題,而是管理面或協調面上出紕漏。比方說奧客亂拗碰上軟腳 sales PM,或是客戶自己都搞不清楚自己要什麼,或是客戶自己山頭林立一人一把號各吹各的調。這種情形下除了等五年後摩爾定律打敗客戶需求之外,找個很會喬夠力喬的高層才是明智之舉。
  • 很多學校都灌輸「演算法改進會優於程式本身改進」這個概念,不過呢,請務必確認您的隊友都了解這個原則是基於「程式本身已經寫的很好」的假設。我看過不少同行花好多好多的時間想要去生出一個更好更棒的演算法,卻沒有去檢查原有程式的品質。爛程式可以很有效地搞砸好的演算法!
  • 如果 team 很大,程式慢就幾乎是必然的,因為程式往往會遷就組織架構而做許多不必要的取捨,例如過度模組化或不必要的流程。這時候通常我們會需要一點來自上層的助力和自己的勇氣才行。

縮短等待時間一般牽扯到的問題反而都不是技術面的,除非一開始設計就很爛,或是很幸運的遇到網路基礎架構很爛的客戶,不然很少會需要什麼技術面的調整。大部份的調整都是屬於心理層面的,所謂 perceptual performance 的東西。比方說,跑一個報表產生的程式,50 頁用了 5 分鐘,客人嫌太慢等很久,放了一個 dialog 上面跑個 progress bar 外加一堆文字閃來閃去顯示報表產生的步驟和進度,50 頁共用了 7 分鐘,客人反而很滿意覺得程式很讚跑的很快 🙂 訣竅很簡單:UI 有在動不會卡住,客人的爽度一般而言比較高。

此外,像拙文記憶體用量的迷思中所寫的現象,雖然與縮短等待時間沒關係,但其實也是 perceptual performance 的另一種表現形式。這種心理層面的效能要怎麼調,得靠 usability 方面做好功課,不然就得和客人拉關係哈啦來補補課學經驗囉。

技術文章, 無責任評論, 狀況排解, 軟體工程 | Comments Jump to the top of this page

Comments are closed.

隨便寫寫大家隨便看看的不出名小格子

舊文索引

站內管理