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

             

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

 
改進后部署圖

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

改進前性能測試

b) 請求DetailListService  web服務的截圖

 

改進后性能測試

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

 

改進前的請求大小比較

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

 

改進后的請求大小比較

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