曾經一個朋友開發了一個項目，客戶端是Windows的應用程序，通過WebService服務操作數據庫。系統的功能都已完成，用戶比較滿意。但是有一個問題存在，就是在查詢時如果讀取大數據量時，系統獲取數據并顯示的等待時間比較長。為了解決這個問題，朋友采用BinaryFormat格式化數據，同時對數據進行壓縮，數據的大小只有原來的8%，效果雖然比以前好一些，但還不是另人滿意。于是朋友繼續找尋著壓縮率更高的壓縮算法。

??????? 我想在開發過程中，很多朋友都會遇到我朋友這樣的情況，當用戶點擊后，等了5秒（還算好），10秒（有點不爽），20秒（系統是不是當掉了），再往后就不敢想了。用個一次兩次的，用戶也許還能接受。如果有段時間需要統計，那用戶還不得給你吹胡子瞪眼睛啊。在遇到大數據量查詢時，我朋友的解決方法也是對的，至少效果比以前好了一些。但問題仍然沒有解決，那么我們是否將注意力集中到其他地方呢？為什么？1、采用壓縮算法后數據只有原來的8%，現行壓縮率更高的算法還能有多少的提升空間；2、業務數據只會更多。

???????? 不考慮除硬件因素，僅考慮技術開發，就這個例子來說明，解決大數據量查詢，通用的做法是采用分頁、格式化并壓縮數據等。可是系統反應速度慢，并不只是WebService的大數據量傳輸的“功勞”，因為從數據獲取到界面顯示經歷了多個環節。要說優化，我想每個環節都可以進行優化。我知道的并不很多，拋磚引玉吧。（建立在上述的例子上，還是優點針對性比較好，不然就要空談了，又要開始Remoting WebService還是 Windows Communication Foundation技術之爭了，那就沒完沒了了。還是那句話：適合才是正確的 ）
?????
???? 1、數據庫。
????????? 我們的數據都是它給的，它的讀取數據的時間對系統的反應速度也是有影響的。對數據庫的優化方式很多了，很多書籍都專門講解如何優化數據庫，比如常用的索引等；存儲過程和SQL語句的選擇；存儲過程和SQL語句的寫法有講究的，表的順序、條件的使用，不是想怎么寫就怎么寫，曾經有朋友做查詢存儲過程，修改了一種寫法，原來半分鐘才出來結果，結果只用幾秒，具體多少忘了，至少用戶可以接受了。

????? 2、應用層。數據庫的API，針對.Net，比如就有DataReader和DataSet的選擇以及轉換等，這個根據具體情況而定；還有呢就是大家常采用的數據的格式化和壓縮，以及采用分頁，減少傳輸的數據量；是否可以把一部分處理邏輯放在客戶端呢，減少服務端的工作量。

?????? 3、數據傳到了界面，界面是否有需要優化的地方呢？如果一個界面打開后所需時間較長，有可能是初始化的工作量太多，是否可以考慮減少在窗體加載時的初始化工作，而放到窗體顯示后呢？這個據具體情況而定；還有就是界面控件的選擇，很多人都使用過第三的控件，第三方控件是較開發平臺提供的功能強大，但因為做的工作比較多，所以效率相對較低。???? 這里需要說明的一點，我做過一個測試，分析兩段時間的百分比，一個是是從數據庫取出數據的時間，一個是控件綁定數據時間（使用的是第三方的控件）。當然例子非常的粗糙，數據庫也沒有進行過優化，因為每次執行機器情況的不盡相同，不足以驗證結論數據的可靠性，只作為一種參考，但我想還是有影響的。數據讀取量從1萬、2萬、5萬、10萬、50萬到100萬不同級別，每個級別都做了3次測試，記錄兩段時間，然后算它們所占總時間的百分比，計算這一級別兩段時間占用時間的平均值，最后將6級別的平均值在進行平均，得到一個結論：使用第三方控件grid數據綁定過程占用40％左右的時間。

??????排除硬件因素，一個系統的優化涉及到很多的方面，不同的項目，不同的環境，就會有不同的優化。我說的只是很多優化中的一角，但不論采用什么方式優化，只要我們堅持，我們的項目將會越來越有競爭力。

????? 我所做的項目有限，積累也就很有限，認識就更有限了，考慮的情況不周全，僅僅只是曾經我在項目中采用該種優化提高了一些的效率的經驗，不好展開，因為太多了，但我說的也不一定正確，大家隨便看看，最歡迎指教。

?

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1504042