在SmartGov3.0發布后，我們就一直在想辦法把在線訪談文字直播所支持的并發性和負載能力至少增加1倍以上，開發部經過一個多月的努力，完成了對線訪談文字直播部分的優化。我們總結了優化的過程分享給可能遇到相同問題的朋友做為參考，非常歡迎大家指出我們的不足，我們會繼續加以改進。
基于在線訪談對高實時性、大并發性和高負載性的需求，我們針對在線訪談模塊分別在多級緩存與緩存的可擴展性、網絡帶寬的節省、多客戶端支持和代碼執行性能等方面進行了改進。
首先我們來看一下改進前后的部署結構圖

             

  在對在線訪談部分改進之前，訪談用戶的寫入時直接存放到數據庫中，而讀取是通過一個緩存的List列表完成。當訪談開始的時候，后臺管理員錄入訪談內容，寫入數據庫，然后更新整個List列表。對于前臺文字直播頁面，首先由DetialList.aspx頁去請求直播內容，DetailList.aspx根據情況是去選擇讀取數據庫還是直接返回List緩存列表。從改進前的請求流程來看，存在著以下問題：
1、添加訪談內容時，會更新整個List列表，而更新整個List列表會讀取數據庫，并且經過監測發現前臺讀取緩存List時緩存命中率也比較低。
2、目前的SmartGov的在線直播是直接采用HttpRuntim.Cache，而不能夠在發布后更改成其他緩存方式。
3、直接采用的是DetialList.aspx頁面來顯示直播內容，而作為前臺動態頁，每次請求的輸出會經過模板綁定、解析、其他多余的HTML代碼、頁面事件等流程。
基于以上問題，我們對在線訪談做多重改進來解決潛在的瓶頸。首先看一下改進后的部署結構圖:
 

 
改進后部署圖

從兩個結構圖的對比來看，改進后的部署結構的復雜性、擴展性有了一個層次的提高。在新的結構下，部署改進了如下內容：
1、可支持獨立的緩存服務器。新的結構圖下，我們既可以沿用原有的部署方式，從而節省硬件的開支。當系統需要支持高負載、高并發的運行環境時，就可以根據所承擔的負載性進行擴展部署，更換緩存接口，實現獨立的緩存服務器（可以通過自己實現我們提供的緩存接口或者定制來滿足要求）。緩存部分可以采用Memcached等其他分布式緩存來代替原來的HttpRuntim.Cache。
2、在代碼方面，我們優化了代碼的執行性能，并且增加了緩存隊列來代替原來的List列表緩存方式。這樣在更新緩存內容時，只更新最新的數據，而不用重新獲取整個List列表。這樣大大的提高了緩存命中率，我們檢測發現文字直播讀取時幾乎不會讀取數據庫，所有的內容都在緩存隊列中。
3、通過直接調用DetialList.aspx來顯示訪談記錄改變成了WebServices的方式，這樣既可以把WebServices來做二級緩存，也可以用來支持多客戶端、多應用程序直播的方式。采用WebServices減少了aspx頁面事件和模板綁定流程，從而會大大減少頁面的請求的時間，更快的反饋給用戶請求結果；采用WebServices減少了頁面大小，降低了對帶寬的需求和節省流量。
a) 對于改進前后我們還使用了測試工具對它們的性能進行了一次測試比較。在沒有改進之前，一次頁面請求大概需要消耗86毫秒的時間，但改進后一次web服務的請求，大概需要消耗22毫秒的時間。從數據上來看，性能幾乎提升了3倍多。
以下為測試請求DetailList.aspx頁面執行Page_Load方法的截圖：
 

改進前性能測試

b) 請求DetailListService  web服務的截圖

 

改進后性能測試

4、節省服務器帶寬，降低應用單位的流量費用。對于訪談數據是采用.NET webservice的方式進行調用。使用這種方式，數據將可以用Json格式或xml格式進行傳輸，相比每次請求的都返回整個HTML格式的頁面數據來看，每次的請求流量比原來頁面方式降低了4倍。
a)  使用firebug來測試頁面的加載流量，下圖是改進前傳輸到客戶端的數據為8kb

 

改進前的請求大小比較

b)  改進后請求返回的數據僅為2KB

 

改進后的請求大小比較

從上面的數據來對比看，內容直接壓縮了4倍左右。返回的數據少，當然加載也就快了。