優化程序的一點建議

　　每一個應用程序到了一定階段由於這個或者那個原因總是需要進行優化的。其中最主要的原因應該是：數據量的增加。但是我們應該怎麼樣去優化一個程序了，我們優化的方法又是否正確了。這讓我想起了一個故事。

　　一個操作系統的編寫人員把系統中的一個基本函數（調用率爲50%）的效率優化了一倍。但是系統性能卻沒有得到應有的提升。原因在於他優化的函數式nop指令，也就是在系統空閒的時候調用的函數。

　　這讓我想起了前一段時間我們系統所做的優化。由於系統發送郵件的數量越來越多，所有郵件堆積的數量和延時也越來越大。這個時候我們使用了基本的優化方法，多線程去發送郵件（多個線程同時連接郵件服務器）。在測試線上的得到的性能提升是非常的大的，但是到了生產線，去經常有連接超時，導致了一些奇怪的問題。最後我們經過和研究和諮詢發現，原來郵件服務器在生產線上一個ip只允許同時5個連接，多了就拒絕。於是我們的努力也就白費了。

　　其實從上面的兩個例子我們可以看到優化程序其實並沒有我們想象的那麼簡單，爲什麼了？因爲很多時候我們面對的並不是技術上的問題，而是業務上的一些變更，而這些變更又往往是我們所不熟悉的。那麼我們應該怎麼樣優化程序了，我覺得以下幾點可以參考。

　　一、優化之前先弄清楚性能的損耗情況，和可以優化的情況。一般情況下，我們遇到的都是比較樂觀的情況，也就是性能損耗最大的地方就是可以優化的地方。但是，且慢，這個“地方”是一個可大可小的詞。爲什麼了？因爲如果宏觀一點來看你會說我們在進行什麼操作的時候會導致性能降低，但是如果微觀一點來看你會說插入數據的時候會產生大量的block，數據庫IO過大，導致操作時間過長。這個時候你該怎麼樣去優化了？

　　二、選擇適度的優化粒度。接着上面的問題，我們可以看到，如果從微觀來看，我們選擇的優化方法可能是對數據庫進行必要的改進，比如，多點commit。但是如果從宏觀的角度來看，我們選擇的就可能使批量提交。這兩種方式各有各的適用地方。我再舉一個例子。

　　我們的項目有一個地方需要向用戶推送客戶提供的html文件（包括圖片，css，js等）但是由於業務原因，我們必須屏蔽掉所有文件的外鏈和處理所有文件的相對路徑引用。這個功能很慢，慢的要死。當時有人提出的方法是改進正則表達式，以提高匹配速度。我提出的是緩存處理結果，所有html文件之處理一次，處理後的數據放到磁盤上，以後再讀的時候就不需要再進行處理了。如果你是經理你會選擇哪一個方案了？

　　三、選擇適當的優化方法。其實優化的方法有很多種，但是不同的方法得到的效果往往是相差很大的。所以在確定適當的方法之前我建議大家還是先做一個簡單的demo，來驗證這個方法的有效性。比如圖片大小的壓縮，很多人是直接使用縮放的形式來實現的，但是縮放會導致一個很嚴重的問題，就是圖片在放大的時候會變得很不清晰。其實有另外兩種方法來實現大小的壓縮，一個是直接改變圖片的質量，另外一個是對圖片進行hsl處理。後面兩個其實連demo都不用自己寫，網上有現成的。

　　四、跳出技術的角度來思考。其實這個是我們很多人的通病（包括我自己）。我們很多時候會鑽牛角尖，會爲一個問題的一個方向浪費很長很長的時間。比如我們在優化郵件投遞的時候就有這樣的一個情況，一個存儲過程奇慢，30秒才查詢出結果（1000條記錄）。於是我們就去想各種各樣的方法去優化，加索引，強制走索引（這個我其實是不贊成的，因爲生產庫由於環境和dba的維護問題，你不一定可以肯定你的索引名稱一定有對應的索引），多處理器處理等等。但是效果都不好。這個時候你會怎麼想？我後來提出的方案是，一次取10000條數據，就算是取數據時間增加爲1分鐘（這其實不大可能的，因爲其實關係型數據庫取數據的條數對速度影響不大），那麼這個取數據的速度也比我們本身投遞郵件的速度要快了。（是不是很簡單？）

　　五、優化的前景。其實這個是很多人都會忽略的。最簡單的就是系統統計的優化，因爲系統統計一般是管理人員用的最多，他們跟我們的關係也是最近的，所以我們一般也會直接選擇優化查詢的性能。但是，不知道你們有沒有想到這樣子的一個問題。這些查詢他們一個月可能才用一次，充其量，一個星期兩次。但是比起優化前臺頁面，比起優化用戶體驗來說優化統計的性價比是極其低的。因爲很多情況下它不會給你增加一分一毫的收益，但是前臺則不同。所以我們現在的產品後臺很爛，以致於運營經常說這不是給人用的，但是我們的經理也只是笑而不語。