2012年7月8日 星期日

導讀與心得:關於軟體的性能調校

今天來寫寫關於這兩篇文章的摘要跟心得:
http://coolshell.cn/articles/2967.html
http://coolshell.cn/articles/7490.html

第一篇文章裡面講的東西很簡單,卻很重要!用 profiler 跟看組語!我個人經常強調的一件事,就是在解決問題的時候一定要先找到問題在哪裡。以前我常用 debugger 來說明,但 debugger 最大的幫助其實不是找出問題,而是「快速的」找出問題。而透過 profiler,對於找出效能問題幾乎是最簡單的作法....(有一種相當土法煉鋼的方法是,在自己的程式碼裡面加上一大堆印出 timestamp 的程式碼,聰明一點的還會用夾擠來避免浪費太多時間。但是這個行為本身就是在浪費時間....)


這篇文章可說是支持了我的觀點,有時候「看起來好像很慢」的程式碼,實際上並不會浪費你太多時間。這是真的!這也是為什麼作者會說,做性能調校要注意兩個重點,一個是花很多時間的程式碼,另一個是被執行很多次的程式碼!看起來很花時間的程式碼,可能不花你很多時間,也不執行很多次!


第二篇文章講的就多了...但這四個步驟的核心觀念很好抓,先定義(效能)需求,然後做測試,接著找出問題,最後解決問題。聽起來很無趣,不是嗎?但常常見到的情況反而是,先看看程式碼,然後猜測問題,修改之後測試看看,最後接受結果。


常見的狀況都是這樣,我自己也是,但在我懂得使用 profiler 之後才終於知道該怎麼把效能問題的重點給抓出來。但這篇文章講得更多,第一步定義 throughput 與 latency,這兩個詞的差別常常被忽略,因為他們會互相影響,所以常被用「performance」給概括了,但其實是可以分開考慮的。


性能測試部份我就比較沒有經驗了,我只懂得使用 profiler 做簡單的分析,但文中所提到的 throughput 與 latency 測試分析,光用想的就很辛苦....更別提還要配合穩定性測試 (舉例來說,如果系統有 memory leak 問題,碰到高 throughput 狀況則可能很容易噴掉)


透過測試,我們可以知道系統效能狀況。可以從兩個角度來看:從外面看,看 CPU 與 IO 的使用率。從裡面看,看系統 profiling 的數據。但其實有個很尷尬的問題,profiler 會稍微降低系統效能,所以對於上線的(且忙碌的)系統來說,想抓到真實狀況又不想對系統造成影響真的很難.....orz


最後談到「解決問題」這就多了,因為不同的問題需要不同的解決方式,我認為文章裡每一條經驗都很值得參考!首先可能要改演算法,演算法對效能的影響,我想寫過 ICPC 比賽或是 UVa Online Judge 的人最清楚了!雖然有很多現實問題真的不是演算法解決的 (都是一些有的沒的雜事),但底下用到的每個演算法都有機會成為瓶頸,也就有可能是系統加速的關鍵。再來,底層會發生的問題也要注意!誰說寫程式不用知道底層?對底層知道的越多,越有可能寫出好程式,這個定律是不會變的...再來講到系統方面的最佳化,這也是對底層知道越多越有用的例子。後面則是講到資料庫...資料庫性能調校相對於系統或是程式語言底層實做來說,應該算是顯學了。但是顯學歸顯學,也不是每個人都了解資料庫,所以「亂調一通然後看看速度多快」反而變成最 popular 的技術了....= = 文章這部份也相當值得閱讀,首先要知道 DB 的 lock 還有其他實做問題,再來可以透過工具看到 SQL query 的 execution plan (這真的很有用!比亂猜好太多了!但有些 RDBMS 要看到 execution plan 相當麻煩= =)。最後則是常見的 SQL 性能問題,像是 full table scan、index 的使用不當,或是某些通常很花時間的功能...

簡單下個結論,軟體性能調校很重要,但是有些人常常沒有用對方法。建議好好讀過這兩篇文章,還有網路上的其他好文章,嘗試看看用比較好的方法做調整!:)

沒有留言:

張貼留言