李曉寧 張浩

摘 要：本文以當前全國各省普通高考網(wǎng)上填報系統(tǒng)因并發(fā)量過高而極易造成網(wǎng)站的癱瘓的現(xiàn)象著手，設計了普通高校招生網(wǎng)上填報志愿系統(tǒng)的高并發(fā)負載解決方案。本系統(tǒng)在盡可能的采用傳統(tǒng)的網(wǎng)站高并發(fā)負載優(yōu)化策略的同時，還針對系統(tǒng)本身的特點從宏觀架構(gòu)及微觀技術(shù)實現(xiàn)手段上都加以研究分析，制定針對網(wǎng)上填報志愿系統(tǒng)的高負載解決方案。宏觀上本系統(tǒng)利用了面向服務的程序設計方式將系統(tǒng)分為網(wǎng)站程序?qū)?、?shù)據(jù)緩存層、數(shù)據(jù)庫層的三層進行設計，實現(xiàn)了系統(tǒng)中應用程序、數(shù)據(jù)操作、數(shù)據(jù)存儲上的物理及邏輯分離，因此系統(tǒng)應對高并發(fā)負載具有了分布式解決能力，實現(xiàn)了系統(tǒng)的可擴展性。微觀上，本系統(tǒng)利用了目前許多提高系統(tǒng)性能的新技術(shù)新方法，使網(wǎng)站程序運行具有了高效性。本系統(tǒng)的有以下幾個特點及創(chuàng)新：（1）架設數(shù)據(jù)緩存庫服務器，建立完善的內(nèi)存數(shù)據(jù)緩存管理機制，利用面向服務的技術(shù)進行網(wǎng)站程序和數(shù)據(jù)緩存之間的通訊。（2）WEB程序與數(shù)據(jù)庫隔離，增加系統(tǒng)的安全性。（3）軟件程序負載均衡與硬件負載均衡結(jié)合應對大并發(fā)訪問。（4）WEB服務器設置內(nèi)存字典，使用哈希表進行數(shù)據(jù)映射，解決頻繁數(shù)據(jù)查詢。（5）網(wǎng)站程序?qū)?、?shù)據(jù)緩存層、數(shù)據(jù)庫層的分層結(jié)構(gòu)設計，方便系統(tǒng)擴展。通過測試和實踐證明，使用多種方法對WEB程序進行優(yōu)化設計及把內(nèi)存數(shù)據(jù)庫作為向數(shù)據(jù)庫中寫入數(shù)據(jù)前的緩沖的思路，能很好的增加網(wǎng)上填報志愿系統(tǒng)一類的大數(shù)據(jù)量的網(wǎng)上應用程序的吞吐能力，從而完成高并發(fā)負載的網(wǎng)上填報志愿需求。

關(guān)鍵詞：高并發(fā) 負載 WCF 內(nèi)存數(shù)據(jù)庫 優(yōu)化

中圖分類號：TP319 文獻標識碼：A 文章編號：1672-3791（2013）03（c）-0043-05

隨著近年來教育部對“陽光工程”的施行和“平行志愿投檔”的推廣，加強了我國高校招生的公平性和透明性。其中“填報志愿”是考生選擇大學的方式，決定著考生一生的發(fā)展道路，因此確保志愿信息采集的公平性、及時性、準確性、安全性也成為了各級招生部門工作的重要環(huán)節(jié)。目前招生部門采用的高考志愿信息采集主要有兩種方式：一是的傳統(tǒng)的涂卡方式，招生部門發(fā)放給考生志愿信息采集卡，由考生根據(jù)學校和專業(yè)代碼填圖志愿后，統(tǒng)一利用光標閱讀機（OMR）進行讀卡；二是開發(fā)網(wǎng)上填報志愿系統(tǒng)（以下簡稱網(wǎng)報系統(tǒng)）利用網(wǎng)頁進行志愿信息采集。網(wǎng)上填報志愿針對過去的錄卡報志愿網(wǎng)報系統(tǒng)有以下幾個方面的優(yōu)勢。

（1）直觀、高效。

考生通過通過互聯(lián)網(wǎng)登錄網(wǎng)報系統(tǒng)?？忌梢栽谙吕藛沃凶龀鲞x擇，填入學校和專業(yè)代碼即可。部分操作熟練的考生十分鐘之內(nèi)就可以完成志愿填報。

（2）簡化流程。

采用讀卡填報志愿方式流程是讓每位考生向老師索取志愿卡后填涂信息，再到招生辦讀出志愿信息，回來后考生改錯，再由招辦工作人員重新改正，然后考生確認信息，這些環(huán)節(jié)不能有半點差錯。網(wǎng)上報志愿簡化了這些流程，考生可以在任何接入互聯(lián)網(wǎng)的電腦上填報志愿并在網(wǎng)上確認。

（3）錯誤率減少。

通過涂卡的方式報志愿時，考生先查找好報考的院校及專業(yè)代碼，然后根據(jù)代碼的數(shù)字在信息卡上相應的代表位置涂黑，由于填涂過程不能直觀的反應出所填報的院校及專業(yè)，所以很容易因涂錯位置而發(fā)生填報錯誤。通過網(wǎng)上報志愿考生所錄入的院校及專業(yè)的代碼可以及時的進行翻譯和校驗，大大減少了填報錯誤的發(fā)生。

采用網(wǎng)上填報志愿是發(fā)展必然趨勢，也是互聯(lián)網(wǎng)高速發(fā)展及計算機普及的產(chǎn)物。隨著部分省份對網(wǎng)上填報志愿的率先嘗試并取得較好的社會反響，網(wǎng)上填報志愿已成為考生志愿信息采集的最好方法。同時，進行網(wǎng)上填報志愿的省份也都面臨著一個嚴峻的問題：由于考生人數(shù)多，并且訪問時間集中同時單個考生修改及查詢頻率又高，極高的瞬時并發(fā)操作請求致使系統(tǒng)和數(shù)據(jù)庫超負荷運行，系統(tǒng)不能及時響應訪問請求，舊的請求還未處理完，新的訪問請求又到來，從而導致服務器處于假死狀態(tài)。一旦進入假死狀態(tài)，用戶的操作就會得不到響應，頁面長時間打不開會延誤考生填報志愿，造成不良的社會影響，甚至致使考生不能完成填報志愿造成重大責任事故。

如何有效的對系統(tǒng)進行高并發(fā)負載已成為網(wǎng)報系統(tǒng)的瓶頸和使用上的軟肋，也制約了網(wǎng)上填報志愿在全國范圍內(nèi)的推廣，目前各省教育考試部門都在針對這一問題進行積極的探索。我們就對這一問題在Asp.net平臺上提出解決方案：根據(jù)木桶原理，要想提高系統(tǒng)的整體能力就需要找到系統(tǒng)的瓶頸加以解決。我們首先分析了整個系統(tǒng)的結(jié)構(gòu)，由于網(wǎng)報系統(tǒng)需要響應大量的考生訪問，并且每個考生的訪問都要進行大量的數(shù)據(jù)查詢存取操作，因此網(wǎng)站不同功能之間的處理能力和速度上的差別也就成為了系統(tǒng)存在的瓶頸。本著為處理壓力較大的模塊增加擴展，為處理速度較慢的模塊設計緩沖這一理念，我們對系統(tǒng)中的應用程序、數(shù)據(jù)操作和數(shù)據(jù)存儲這三大應用功能進行了分層設計，將系統(tǒng)分為網(wǎng)站程序?qū)印⒕彺鏀?shù)據(jù)庫層和數(shù)據(jù)庫層。網(wǎng)站程序處理壓力大，該層要進行可擴展性設計；數(shù)據(jù)庫層存在速度較慢，該層要由數(shù)據(jù)緩存層進行緩沖設計，（如圖1）所示。下面分別對各層的設計進行分析。

1 網(wǎng)站程序?qū)?/p>

該層使用最新的ASP.NET技術(shù)進行開發(fā)，部署在WEB服務器上。肩負著同考生進行交互，實現(xiàn)志愿填報業(yè)務邏輯；完成志愿代碼翻譯查詢，通過WCF服務從數(shù)據(jù)緩存層中讀取數(shù)據(jù)。由于該層的負載壓力大，因此需要很好的橫向擴展設計。

（1）負載均衡。

同時由于程序的主要負載都集中在網(wǎng)站程序上，為了應對大并發(fā)的負載，我們把網(wǎng)站程序在每臺WEB服務器上都設計為獨立運行，采用F5負載均衡設備為用戶訪問提供20分鐘的會話保持。這樣就為程序提高了良好的橫向擴展性和可靠性，如果WEB服務出現(xiàn)負載飽和時，只需添加服務器即可實現(xiàn)負載分流，（如圖2）所示。

（2）內(nèi)存數(shù)據(jù)字典。

在填報志愿過程中查詢最頻繁的就是計劃表，計劃庫表放著招生院校的層次、批次和其專業(yè)的科類、計劃性質(zhì)等信息，總記錄數(shù)為3萬條左右。通過計劃表查詢將考生填寫的院校編碼和專業(yè)編碼翻譯成院校名稱和專業(yè)名稱，并判斷考生是否將院校代碼和專業(yè)填錯并提醒考生不要誤報達不到要求的專業(yè)浪費報考機會，因此計劃表能否正確、高效、快速的查詢對網(wǎng)報系統(tǒng)能否正常運行起著至關(guān)重要的作用。以某省50萬考生來計算，對計劃表的查詢量達十一億次，顯然在集中的時間段內(nèi)應對如此大量的查詢請求數(shù)據(jù)庫已經(jīng)很難負載。內(nèi)存數(shù)據(jù)字典，是將計劃表在程序首次運行時加載到每臺WEB服務器內(nèi)存中，可供程序直接在內(nèi)存中訪問的數(shù)據(jù)集合。通過測試內(nèi)存的讀取速度為18000多M/S，寫入速度在15000左右（HP GX580服務器），而現(xiàn)在最好的固態(tài)硬盤讀取速度也就能到400多M/S，相對于磁盤內(nèi)存的數(shù)據(jù)讀寫速度要高出幾個數(shù)量級。所以從內(nèi)存中讀取數(shù)據(jù)相比從磁盤上讀取能夠極大地減少查詢時間提高應用的性。

2 數(shù)據(jù)緩存層

在填報志愿過程中，按50萬考生每個考生可以填報8個批次，每個批次可以填報5所院校，其中1秒中有1000個考生在操作志愿數(shù)據(jù)的情況下計算，就要滿足1秒鐘內(nèi)在兩千多萬記錄中進行四萬次數(shù)據(jù)修改操作的需求。面對苛刻的高并發(fā)負載需求，傳統(tǒng)數(shù)據(jù)庫很難實現(xiàn)。要完成如果高速的操作，IO速度極高的內(nèi)存將會是最合適的場所，所以需要自行開發(fā)內(nèi)存數(shù)據(jù)庫作為數(shù)據(jù)緩存層來實現(xiàn)這一需求。該層是整個網(wǎng)報系統(tǒng)的數(shù)據(jù)處理中心，部署在專門設立的緩存服務器上。數(shù)據(jù)緩存層運行有一套完成的數(shù)據(jù)維護機制。實現(xiàn)增、刪、查、改的數(shù)據(jù)操作；實現(xiàn)監(jiān)聽、應答的通訊機制；實現(xiàn)數(shù)據(jù)備份和回復功能。作為網(wǎng)站程序?qū)雍蛿?shù)據(jù)庫層的速度差異緩沖，該層也就成為了系統(tǒng)中數(shù)據(jù)操作、交互的核心。

構(gòu)建內(nèi)存數(shù)據(jù)緩存層后，我們對內(nèi)存數(shù)據(jù)庫和SQLSERVER數(shù)據(jù)庫進行了2萬次數(shù)據(jù)讀寫效率對比測試，如圖3所示。

設計時我們需要考慮以下幾個方面。

（1）數(shù)據(jù)操作模式。

作為內(nèi)存數(shù)據(jù)庫和前面的內(nèi)存字典不一樣，不僅僅要完成對數(shù)據(jù)的查詢請求，還要完成對數(shù)據(jù)的增加、刪除、修改的操作。

（2）通訊機制。

如果沒有通訊內(nèi)存數(shù)據(jù)庫就是聾子和啞巴，對外是發(fā)揮不了任何作用的，因此在內(nèi)存數(shù)據(jù)庫中還要建立對請求的監(jiān)聽和應答機制。

（3）數(shù)據(jù)備份。

內(nèi)存作為高速暫時存儲器，其數(shù)據(jù)在斷電后會立刻丟失，因此要將內(nèi)存中的數(shù)據(jù)寫入到數(shù)據(jù)庫中并妥善存儲在硬盤上才能確保數(shù)據(jù)不會丟失。

我們將上述功能通過數(shù)據(jù)緩存、通訊、調(diào)度三個模塊來實現(xiàn)，這些模塊的分工如下。

（1）數(shù)據(jù)緩存模塊。

該模塊負責在內(nèi)存中存放數(shù)據(jù)，并在運行期間維護數(shù)據(jù)的完整性；數(shù)據(jù)緩存層初始化運行時從數(shù)據(jù)庫中加載數(shù)據(jù)并建立索引；提供數(shù)據(jù)查詢接口函數(shù)；定時將改動的數(shù)據(jù)以xml文件保存到硬盤上供調(diào)度程序?qū)懭霐?shù)據(jù)庫。該模塊是內(nèi)存數(shù)據(jù)庫的實現(xiàn)基礎(chǔ)，由于這些功是在內(nèi)存中實現(xiàn)，需要考慮以下幾個方面。

①數(shù)據(jù)占用空間。

在志愿表中一條考生志愿信息經(jīng)計算形成數(shù)據(jù)對象存儲后每條記錄的大小為1K左右。按50萬考生每個考生填報8個批次，每批報5所院校計算，內(nèi)存數(shù)據(jù)庫中所存儲的數(shù)據(jù)最大容量為22400000×1K，即22.4GB。加上windows2008和WCF服務需要占用的2～3G內(nèi)存空間，我們需求的最低內(nèi)存容量為26GB。

②數(shù)據(jù)安全。

內(nèi)存作為暫存器，斷電后造成數(shù)據(jù)丟失，針對該問題我們采用了定時增量日志備份來完成，即內(nèi)存數(shù)據(jù)庫每隔1秒鐘（這個時間間隔可以任意設置）會將每次對數(shù)據(jù)進行的修改操作以XML格式存儲為操作日志文件。如果發(fā)生斷電事故，最多會丟失1秒鐘內(nèi)未及時保存到磁盤的操作日志，因此可以將事故影響控制在可控范圍之內(nèi)。

③存放形式。

內(nèi)存中數(shù)據(jù)存放的方式有很多種選擇，如數(shù)組、鏈表、隊列、哈希表、字典等。通過對數(shù)據(jù)操作的分析，緩存服務形式就是以最快的速度響應網(wǎng)站程序?qū)拥淖x寫請求，所以最重要的因素就是從海量數(shù)據(jù)中定位單條數(shù)據(jù)的速度，因此哈希表是承載數(shù)據(jù)的最佳形式。

④數(shù)據(jù)查詢。

內(nèi)存表在建立后查詢操作是通過在哈希表中建立關(guān)鍵碼來完成的，查詢效率很高。在考生數(shù)據(jù)表中，我們通過初始化在具有唯一性的考生號來設立關(guān)鍵碼并預留查函數(shù)接口來構(gòu)建查詢語句，根據(jù)通訊模塊調(diào)用傳遞的參數(shù)篩選符合條件的數(shù)據(jù)并返回。

（2）通訊模塊。

通訊模塊實現(xiàn)了數(shù)據(jù)緩存層與網(wǎng)絡程序?qū)又g的交互，因此該模塊最為關(guān)鍵之處就是要建立一個可靠、高效的監(jiān)聽、應答機制。我們采用了WCF服務去完成這種監(jiān)聽應答機制。WCF（Windows Communication Foundation）是由微軟公司發(fā)展的一組數(shù)據(jù)通信的應用程序開發(fā)接口，WCF構(gòu)建了一個在互聯(lián)系統(tǒng)中實現(xiàn)各個應用程序之間通信的分布式框架。在該框架內(nèi)數(shù)據(jù)緩存層的通訊模塊與網(wǎng)站程序?qū)拥臄?shù)據(jù)訪問類之間通過契約實現(xiàn)數(shù)據(jù)請求操作，與訪問請求發(fā)起者無關(guān)，從而使網(wǎng)站程序?qū)拥拿颗_服務器進行的訪問操作都是相互的獨立的，為網(wǎng)站程序?qū)拥目蓴U展性提供了保障。

（3）調(diào)度模塊。

該模塊負責數(shù)據(jù)緩存增量日志的定時備份；負責將數(shù)據(jù)緩存模塊保存的數(shù)據(jù)改動文件寫入到數(shù)據(jù)庫層中，將數(shù)據(jù)持久化。調(diào)度模塊負責內(nèi)存數(shù)據(jù)庫與SQLSEVER數(shù)據(jù)庫之間的同步，是數(shù)據(jù)緩存層與數(shù)據(jù)庫層之間的橋梁。

調(diào)度模塊的運行機制是：數(shù)據(jù)緩存模塊每1秒鐘將發(fā)生變化的數(shù)據(jù)以一個XML文件的形式寫入磁盤中，調(diào)度模塊每隔5秒中（時間可以自行設定）將這些文件讀取寫并將這些操作寫入數(shù)據(jù)庫，然后這些XML文件壓縮打包后移動到磁盤中設定的備份目錄中。在大并發(fā)訪問發(fā)生時，因數(shù)據(jù)庫操作寫入速度遠比不上內(nèi)存數(shù)據(jù)庫的操作速度，這時會發(fā)生待寫入XML文件的積攢的現(xiàn)象，但是只要有內(nèi)存數(shù)據(jù)庫操作量較小于數(shù)據(jù)庫寫入的時段出現(xiàn)，這部分積攢的操作文件就可以按時間順序被逐漸寫入。通過這樣的原理，數(shù)據(jù)緩存層為數(shù)據(jù)庫層起到了緩沖的作用。

通過這樣的運行機制數(shù)據(jù)緩存層會在運行過程中就會產(chǎn)生一個可操作的數(shù)據(jù)庫副本和一個日志副本，這時如果數(shù)據(jù)庫發(fā)生故障，我們可以將保存的xml文件解壓后重新寫入到數(shù)據(jù)中，為系統(tǒng)的數(shù)據(jù)安全性提供了雙重保障。

由于數(shù)據(jù)緩存層的操作量會很大，要將這些操作保存在文件中，這就涉及到內(nèi)存對象序列化。使用xml序列化內(nèi)存對象，結(jié)果簡潔，讀寫效率高，同時也便于在一個文件中序列化多條數(shù)據(jù)，如圖4所示。

3 數(shù)據(jù)庫層

在網(wǎng)報系統(tǒng)中，由于采用了數(shù)據(jù)緩存層的設計，數(shù)據(jù)操作壓力集中在了內(nèi)存數(shù)據(jù)庫中，而SQLSERVER僅作為數(shù)據(jù)持久存儲和少量的管理用數(shù)據(jù)查詢挖掘使用，因此網(wǎng)報系統(tǒng)中僅使用了一臺服務器作為數(shù)據(jù)庫服務器使用。

4 系統(tǒng)測試

構(gòu)建測試環(huán)境

為了詳盡的對網(wǎng)報系統(tǒng)進行測試，確保系統(tǒng)的穩(wěn)定運行。我們構(gòu)建一個較為接近實際情況的運行實驗環(huán)境。該環(huán)境包括以下幾點。

（1）網(wǎng)報系統(tǒng)部署：測試環(huán)境中使用了7臺HP服務器。分配為：WEB服務器4臺，部署相同的網(wǎng)站程序?qū)樱籛CF服務器2臺，一臺部署通訊模塊和數(shù)據(jù)緩存模塊，一臺部署調(diào)度模塊并且用于XML文件備份；數(shù)據(jù)庫服務器1臺，部署數(shù)據(jù)庫層。服務器部署情況如圖5所示。

（2）網(wǎng)絡部署：采用實際應用狀態(tài)下網(wǎng)絡拓撲結(jié)構(gòu)，通過F5對WEB服務器進行負載均衡，具體網(wǎng)絡結(jié)構(gòu)如圖6所示。

（3）測試服務器：采用1臺HP580服務器，用于測試軟件安裝，測試工具LoadRunner （V8.1）。

（4）測試方法：本次測試包括功能測試和性能測試。

功能測試：即黑盒測試，測試人員在了解被測評目標的功能規(guī)格、高層設計和操作規(guī)范等的基礎(chǔ)上，測試被測系統(tǒng)的可用性。

性能測試：對系統(tǒng)在多種并發(fā)連接數(shù)情況下的處理能力進行測試。本次測試主要采用Dynamic workload（動態(tài)負載模型）逐步增加并發(fā)用戶數(shù)，給系統(tǒng)逐步加載壓力，并且讓系統(tǒng)在該負載條件下持續(xù)運行一段時間，然后逐漸減少并發(fā)用戶數(shù)，檢驗被測系統(tǒng)是否能夠穩(wěn)定運行，同時監(jiān)測Web服務器和緩存服務器的性能。

志愿填報測試。

（1）測試目的。

分別測試從網(wǎng)站程序?qū)觾?nèi)網(wǎng)單臺web服務器接入和外網(wǎng)4臺WEB服務器負載均衡接入網(wǎng)上填報志愿系統(tǒng)，測試在多用戶并發(fā)登錄時的處理能力。

（2）測試步驟。

①從內(nèi)網(wǎng)單臺WEB服務器接入網(wǎng)報系統(tǒng)，驗證系統(tǒng)“志愿填報和修改”功能可用。

②利用LoadRunner錄制并保存為“tiaobao”的腳本，對腳本中實時參數(shù)VIEWSTATE和考生考號進行參數(shù)化。

③啟動LoadRunner負載生成器，加載“tianbao”腳本，設置并發(fā)用戶數(shù)為200，設置持續(xù)運行時間為“5 min”，并且選擇“運行前初始化所有Vuser”。

④執(zhí)行負載測試，運行完成后，啟動“Mercury LoadRunner Analysis”生成并保存測試結(jié)果。

⑤依次調(diào)整步驟③中的并發(fā)用戶數(shù)為200、500、1000、1500、2000、2500，并分別重復步驟③～步驟④。

⑥從外網(wǎng)通過F5負載均衡4臺WEB服務器接入網(wǎng)報系統(tǒng)，并分別重復步驟②～步驟⑤，由于會話保持策略會持續(xù)將訪問指向同一臺服務器，此時將會話保持和session驗證均去掉，采用隨機發(fā)牌模式測試。

測試結(jié)果如表1所示，事物響應時間對比如圖7、8所示。

5 測試結(jié)果分析

測試期間在上述壓力條件下，從內(nèi)網(wǎng)單臺服務器接入，占用了200 Mbps的帶寬，服務器CPU滿負荷運行，系統(tǒng)運行正常。從外網(wǎng)負載均衡接入，此時由4臺服務器共同負載，占用了500 Mbps的帶寬，服務器CPU資源有富余，平均事務響應時間遠低于內(nèi)網(wǎng)，但性能沒有出現(xiàn)理論上的4倍提升，由此可見網(wǎng)絡設備會帶來一定的效率損耗，應用系統(tǒng)自身運行正常。性能測試完成后，CPU和內(nèi)存占用均回落至正常水平，未出現(xiàn)內(nèi)存泄露現(xiàn)象。

通過測試看出WCF數(shù)據(jù)緩存層成功的實現(xiàn)了高并發(fā)負載下的內(nèi)存數(shù)據(jù)庫功能，在數(shù)據(jù)庫操繁忙的情況下為數(shù)據(jù)庫起到了緩沖的作用。通過F5負載均衡設備成功實現(xiàn)了WEB服務器的負載均衡，雖然單臺WEB服務器有一定的效率損耗，但是卻帶來了網(wǎng)站程序?qū)拥目蓴U展性，實戰(zhàn)狀態(tài)下如果系統(tǒng)出現(xiàn)負荷過高的情況，只需增加WEB服務器的數(shù)量即可實現(xiàn)系統(tǒng)性能的提升。

6 結(jié)論

實踐證明，對網(wǎng)報系統(tǒng)進行分層，網(wǎng)站程序進行可擴展設計和把內(nèi)存數(shù)據(jù)庫作為向數(shù)據(jù)庫中寫入數(shù)據(jù)前的緩沖的思路，能很好的增加網(wǎng)上填報志愿系統(tǒng)一類的大數(shù)據(jù)量的網(wǎng)上應用程序的吞吐能力，從而完成高并發(fā)負載的網(wǎng)上填報志愿需求。不足之處是，這種形式需要占用大量的內(nèi)存，對服務器內(nèi)存有一定的硬件要求。在方案思路的基礎(chǔ)上還可以對以下幾方面進行完善。

（1）考慮將數(shù)據(jù)緩存層轉(zhuǎn)化為分布式應用系統(tǒng)從而增強其負載的數(shù)據(jù)量和安全性。

（2）數(shù)據(jù)在內(nèi)存中的保存形式針對具體的業(yè)務應用做進一步的優(yōu)化，在性能上還有挖掘的潛力。

（3）Xml數(shù)據(jù)文件在保存在磁盤上的操作可以考慮放在固態(tài)硬盤上可以能進一步提高讀寫性能。

參考文獻

[1]奚江華.圣殿祭司的ASP.NET3.5開發(fā)詳解II[M].電子工業(yè)出版社，2008.

[2]金益民.一種基于XML的WEB數(shù)據(jù)庫應用模型研究及應用[J].現(xiàn)代電子技術(shù)，2004.

[3]蔣金楠.WCF技術(shù)剖析[M].電子工業(yè)出版社，2009，6.

[8]曾凱，曾斌，楊英，等.擴展SQL跟蹤數(shù)據(jù)技術(shù)在數(shù)據(jù)性能診斷上的應用[J].計算機應用與軟件，2006，23（1）：128-130.

[9]盧成均.多層模式下通用數(shù)據(jù)存取層的設計與實現(xiàn)[J].計算機工程與設計，2007，28（13）：3265-3269.

[10]Andrews A，Offutt J，Alexander R.Testing Web applications by modeling with FSMS[J].Software Systems and Modeling，2005，4（3）：326-345.

[11]王昌輝，王遠景.基于URL路徑的Web信息檢索模型的研究[J].貴州教育學院學報（自然科學），2008，19：36-39.

[12]尚俊杰，秦衛(wèi)中.ASP.NET程序設計案例教程[M].北京：清華大學出版社，2005.