導讀與心得：關於軟體的性能調校
標籤： 心得
今天來寫寫關於這兩篇文章的摘要跟心得：
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 的使用不當，或是某些通常很花時間的功能...
簡單下個結論，軟體性能調校很重要，但是有些人常常沒有用對方法。建議好好讀過這兩篇文章，還有網路上的其他好文章，嘗試看看用比較好的方法做調整！:)
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 的使用不當，或是某些通常很花時間的功能...
簡單下個結論，軟體性能調校很重要，但是有些人常常沒有用對方法。建議好好讀過這兩篇文章，還有網路上的其他好文章，嘗試看看用比較好的方法做調整！:)
沒有留言:
張貼留言