主要考慮的Servlet版運(yùn)行方式有：

　　一：Servlet在Web容器中的運(yùn)行機(jī)制

　　1． 單獨(dú)一個(gè)無狀態(tài)的Servlet實(shí)例運(yùn)行

　　即Web容器里的多個(gè)線程調(diào)用一個(gè)Servlet實(shí)例的運(yùn)行方式

　　2． 多個(gè)Servlet實(shí)例

　　在Web容器中有多個(gè)Servlet實(shí)例的對象池，并有多個(gè)Web容器線程來分別調(diào)用執(zhí)行

　　二：Servlet 連接數(shù)據(jù)庫的方式

　　1． 一對一

　　即可每個(gè)Servlet實(shí)例都有直接的數(shù)據(jù)庫連接。

　　具體方式有：

　　1> 在Servlet實(shí)例的每個(gè)處理方法中每次都調(diào)用數(shù)據(jù)庫連接，然后用此連接進(jìn)行數(shù)據(jù)庫的查詢等操作，最后關(guān)閉并釋放此連接。

　　2> 在Servlet實(shí)例的初始化操作時(shí)就連接一個(gè)“長”的數(shù)據(jù)庫連接，直到Servlet實(shí)例在destroy時(shí)關(guān)閉并釋放此數(shù)據(jù)庫連接。

　　因?yàn)楝F(xiàn)在的數(shù)據(jù)庫操作主要是查詢，沒有對數(shù)據(jù)庫的增加、修改等操作，多用戶業(yè)務(wù)查詢、Web容器多線程同時(shí)對一個(gè)Servlet的同一個(gè)數(shù)據(jù)庫連接進(jìn)行操作應(yīng)該會(huì)沒有數(shù)據(jù)操作同步等問題。

　　2． 使用Web容器的數(shù)據(jù)源

　　這里主要是使用Web容器的數(shù)據(jù)源－數(shù)據(jù)庫連接池。

　　在理論上這種方式能提供最佳的性能。這是也是測試各種Web容器產(chǎn)品在數(shù)據(jù)庫連接池上實(shí)現(xiàn)的性能情況。

　　這里主要看Web容器的在各種應(yīng)用情況下的最優(yōu)化配置。

　　Servlet與數(shù)據(jù)源連接的實(shí)現(xiàn)方式：

　　Servlet直接從Web容器配置中取得數(shù)據(jù)源及其連接對象，然后通過此連接對象來操作數(shù)據(jù)庫。對于數(shù)據(jù)庫連接對象的管理由Web容器來管理。

　　三：要考慮的問題：

　　1． 大數(shù)據(jù)量傳輸問題

　　大數(shù)據(jù)量通過Servlet實(shí)例從數(shù)據(jù)庫中取得并整理后，如何有效的傳輸?shù)娇蛻舳薎E，并且Servlet實(shí)例如何有效在Web容器中處理這些大數(shù)據(jù)量。

　　2． 對各種JDBC版本的測試

　　即不同的數(shù)據(jù)庫使用其自己專用的JDBC來連接，在性能上應(yīng)該要好一些。

　　這里也可比較Weblogic Server中實(shí)現(xiàn)JDBC與各種數(shù)據(jù)庫（MSSQL、Oracle）專用的差別，從測試的結(jié)果看出Weblogic Server的技術(shù)實(shí)例以及是否真正做到了數(shù)據(jù)庫連接等處理的優(yōu)化了嗎。

　　3． Weblogic Server的優(yōu)化配置

　　3．1 對象池配置

　　包括應(yīng)用邏輯處理對象的對象池化以及使用數(shù)據(jù)源時(shí)的數(shù)據(jù)庫連接對象池在各種具體應(yīng)用環(huán)境下的優(yōu)化配置。

　　3．2 線程池配置

　　以上兩個(gè)方面涉及到對象池化和串行化處理的策略。

　　3．3 Weblogic Server 的配置的各種參數(shù)的相應(yīng)情況下的配置

　　1> JAVA VM (JAVA 虛擬機(jī))參數(shù)在各種應(yīng)用情況下的配置。

　　2> Weblogic Server 本身的各種參數(shù)配置。

　　鑒于以上的考慮對Servlet版的測試規(guī)劃為以下幾種測試用例：

　　序號 部署包名(*.JAR *.WAR *.EAR 等) 數(shù)據(jù)源配置 Weblogic Server

　　的配置 預(yù)期結(jié)果 說明 可能出現(xiàn)的問題和現(xiàn)象

　　1 ServletQueryForPerConn.war 在每此業(yè)務(wù)處理時(shí)創(chuàng)建數(shù)據(jù)庫連接，操作完畢后關(guān)閉并釋放。

　　通過Web.xml配置文件來配置JDBC的驅(qū)動(dòng)類型和連接。 直接部署ServletQueryForPerConn.jar部署包。

　　Web容器中只有一個(gè)Serverlet實(shí)例。

　　建議配置較多的線程數(shù)量。

　　性能差。

　　在每此業(yè)務(wù)處理時(shí)創(chuàng)建數(shù)據(jù)庫連接，操作完畢后關(guān)閉并釋放。

　　此包中沒有設(shè)計(jì)到線程同步的有關(guān)代碼。 數(shù)據(jù)庫很忙（因?yàn)閿?shù)據(jù)庫要接收頻繁的數(shù)據(jù)庫連接）。

　　可能瓶頸在數(shù)據(jù)庫對頻繁的連接處理。

　　數(shù)據(jù)庫事務(wù)方面：由于是在每次處理時(shí)就調(diào)用數(shù)據(jù)庫連接并查詢，因此數(shù)據(jù)庫的事務(wù)處理應(yīng)該是單獨(dú)在一個(gè)獨(dú)立的處理過程中，與并行的其他線程的處理沒有關(guān)系。

　　2 ServletQueryForOnceConn.war Servlet對象只是的初始化時(shí)連接與數(shù)據(jù)庫的一個(gè)連接，在以后的操作中式中使用這個(gè)連接。

　　通過Web.xml配置文件來配置JDBC的驅(qū)動(dòng)類型和連接。 直接部署ServletQueryForOnceConn.jar包；

　　Web容器只有一個(gè)Servlet實(shí)例。

　　建議配置較多的線程數(shù)量。

　　性能較差。

　　Servlet對象只是的初始化時(shí)連接與數(shù)據(jù)庫的一個(gè)連接，在以后的操作中式中使用這個(gè)連接。

　　此包中沒有設(shè)計(jì)到線程同步的有關(guān)代碼。 數(shù)據(jù)庫連接只有一個(gè)。

　　可能瓶頸在Web容器的多個(gè)線程對同一個(gè)數(shù)據(jù)庫連接對象的同步等處理（這些同步處理是Web容器自己管理的）。

　　可能出現(xiàn)查詢的數(shù)據(jù)在多個(gè)客戶請求中打亂（因?yàn)橥瑫r(shí)使用同一個(gè)數(shù)據(jù)庫通信通道）；

　　并且多個(gè)線程（單獨(dú)的處理單元）可能會(huì)在同一個(gè)處理事務(wù)中，可能各個(gè)處理單元會(huì)串行操作數(shù)據(jù)庫（這要看數(shù)據(jù)庫的具體實(shí)現(xiàn)了）。

　　3 ServletQueryForConnPool.war 直接使用Web容器的數(shù)據(jù)源和數(shù)據(jù)庫連接池。 配置數(shù)據(jù)源及數(shù)據(jù)庫連接池。

　　建議根據(jù)實(shí)際情況優(yōu)化配置數(shù)據(jù)源和連接池。如可建立多個(gè)連接池等配置。 性能好。 Servlet實(shí)例不管數(shù)據(jù)庫連接，而是直接從Web容器中取得數(shù)據(jù)庫連接。數(shù)據(jù)庫的連接對象有Web容器全權(quán)管理。

　　此包中沒有設(shè)計(jì)到線程同步的有關(guān)代碼。 對Web容器的數(shù)據(jù)庫連接池的配置可能要根據(jù)具體情況進(jìn)行有效的調(diào)整（如數(shù)據(jù)庫連接對象個(gè)數(shù)和Web容器配額的線程個(gè)數(shù)的關(guān)系等）。如果配置不佳可能是性能瓶頸在Web容器或者在數(shù)據(jù)庫方。

　　4 ServletQueryForConnPool.war

　?。ㄍ瑴y試3） 同測試3 Web容器的數(shù)據(jù)源重新配置為數(shù)據(jù)庫產(chǎn)品專用的JDBC驅(qū)動(dòng)器。 性能好。 測試目的是比較各種不同的JDBC數(shù)據(jù)連接驅(qū)動(dòng)器的性能，以便得出根據(jù)不同的數(shù)據(jù)庫產(chǎn)品選擇最佳的JDBC驅(qū)動(dòng)器。

　　只測試數(shù)據(jù)庫產(chǎn)品提供的專用JDBC驅(qū)動(dòng)器。

　　（說明：因?yàn)闇y試3在理論上性能是最好，因此選用測試3。測試方法和測試3一樣，這樣才有可比性。） 同測試3。

　　5 servletQueryDS_Cache.war 同測試3 同測試3 性能一般

　　使用一變量來緩存查詢的數(shù)據(jù)，用戶以后的分頁查詢查詢操作是直接從此緩存中取得的。

　　這種方式對Web容器的內(nèi)存要求高，效果不是很好，對數(shù)據(jù)量查詢小的效果可能會(huì)好些。 優(yōu)點(diǎn)：

　　減少的了對數(shù)據(jù)庫訪問的次數(shù)。

　　缺點(diǎn)：

　　需要較大的內(nèi)存。對Weblogic容器的內(nèi)存要求高，對于有大量用戶的查詢操作，并且查詢的結(jié)果集較大時(shí)，可能對整個(gè)系統(tǒng)的性能是個(gè)很大的瓶頸。

　　

　　對大量數(shù)據(jù)的分頁處理

　　問題描述：

　　背景1：一客戶通過IE請求Web服務(wù)器查詢數(shù)據(jù)，而查詢結(jié)果是上千條甚至是上萬條記錄，要求查詢結(jié)果傳送到IE客戶端并分頁顯示。

　　背景2：一客戶通過IE或者其他方式請求Web服務(wù)器查詢數(shù)據(jù)，而查詢結(jié)果是上千條甚至是上萬條記錄，并要求查詢結(jié)果把包傳送到客戶的E-mail中。

　　問：對于這樣的有大量數(shù)據(jù)的結(jié)果集，在Web服務(wù)器端如何有效的處理？

　　可能涉及到的問題：

　　1． 內(nèi)存占用

　　大量數(shù)據(jù)的結(jié)果集，可能要

　　2． 傳輸速度及策略

　　具體的分頁處理技術(shù)

　　

　　序號 名稱 處理方法 針對的數(shù)據(jù)庫 例子說明 備注

　　1 游標(biāo)查詢 直接使用ResultSet來處理。ResultSet是直接在數(shù)據(jù)庫上建立游標(biāo)，然后通過ResultSet的行位置定位接口來獲得指定行位置的記錄。

　　當(dāng)用戶第一請求數(shù)據(jù)查詢時(shí)，就執(zhí)行SQL語句查詢，獲得的ResultSet對象及其要使用的連接對象都保存到其對應(yīng)的會(huì)話對象中。

　　以后的分頁查詢都通過第一次執(zhí)行SQL獲得的ResultSet對象定位取得指定行位置的記錄。

　　最后在用戶不再進(jìn)行分頁查詢時(shí)或會(huì)話關(guān)閉時(shí)，釋放數(shù)據(jù)庫連接和ResultSet對象等數(shù)據(jù)庫訪問資源。

　　說明：在用例分頁查詢的整個(gè)會(huì)話期間，一個(gè)用戶的分頁查詢就要占用一個(gè)數(shù)據(jù)庫連接對象和結(jié)果集的游標(biāo)，這種方式對數(shù)據(jù)庫的訪問資源占用比較大，并且其利用率不是很高。 所有的數(shù)據(jù)庫產(chǎn)品。 優(yōu)點(diǎn)：

　　減少了數(shù)據(jù)庫連接對象的多次分配獲取，減少了對數(shù)據(jù)庫的SQL查詢執(zhí)行。

　　缺點(diǎn)：

　　占用數(shù)據(jù)庫訪問資源－數(shù)據(jù)庫連接對象，并占用了數(shù)據(jù)庫上的資源－游標(biāo)。而這些資源都是十分寶貴的有限制的。

　　結(jié)論：

　　這種的數(shù)據(jù)庫查詢分頁處理方式不是最佳的。一般不適用這種方式。

　　2 定位行集SQL查詢 主要是直接使用數(shù)據(jù)庫產(chǎn)品的提供的對查詢的結(jié)果集可定位行范圍的SQL接口技術(shù)。

　　在用戶的分頁面查詢請求中，每次可取得查詢請求的行范圍的參數(shù)，然后使用這些參數(shù)生產(chǎn)取得指定行范圍的的SQL查詢語句，然后每次請求獲得一個(gè)數(shù)據(jù)庫連接對象并執(zhí)行SQL查詢，把查詢的結(jié)果返回給用戶，最后釋放說有的數(shù)據(jù)庫訪問資源。

　　說明：這種方式需要每次請求時(shí)都要執(zhí)行數(shù)據(jù)庫的SQL查詢語句；對數(shù)據(jù)庫的訪問資源是使用完就立即釋放，不白白占用數(shù)據(jù)庫訪問資源。 對特定（提供了對查詢結(jié)果集可定位功能的）的數(shù)據(jù)庫產(chǎn)品。

　　如：Oracle,DB2, PostgreSQL,mySQL等。(MS SQL Server 沒有提供此技術(shù)。) 如:

　　1． Oracle數(shù)據(jù)庫使用關(guān)鍵字：rowid或rownum

　　2． DB2:

　　rowid或rownum ()

　　3． PostgreSQL 使用LIMIT 和 OFFSET

　　4． MySQL 使用Limit 優(yōu)點(diǎn)：

　　這種技術(shù)是直接使用數(shù)據(jù)庫產(chǎn)品自己提供的可對查詢結(jié)果集定位行范圍過濾的功能，因此直接利用了數(shù)據(jù)庫的性能對此分頁查詢的優(yōu)化功能。

　　對數(shù)據(jù)庫的訪問資源（數(shù)據(jù)庫連接對象，數(shù)據(jù)庫游標(biāo)等）沒有浪費(fèi)，這些資源的充分重復(fù)的利用。

　　對查詢的結(jié)果對Web容器沒有什么特別要求。

　　缺點(diǎn)：

　　要執(zhí)行多次數(shù)據(jù)庫SQL查詢操作。對每次的分頁面操作請求都要指定相應(yīng)范圍的結(jié)果集來執(zhí)行SQL語句的數(shù)據(jù)庫查詢操作，這對數(shù)據(jù)庫有一定的影響。

　　對每次分頁面查詢請求要頻繁的從Web容器中獲得數(shù)據(jù)庫訪問資源（數(shù)據(jù)庫連接對象和數(shù)據(jù)庫游標(biāo)）。

　　要依賴于具體的數(shù)據(jù)庫產(chǎn)品。因?yàn)閷]有實(shí)現(xiàn)沒有提供此技術(shù)的數(shù)據(jù)庫產(chǎn)品不能使用此方式。

　　結(jié)論：

　　由于每次對數(shù)據(jù)庫的SQL查詢操作相對而言耗用的數(shù)據(jù)資源比較少，并且在實(shí)際用戶的操作中，有可能用戶對查詢的所有結(jié)果集只是需要查看其中的部分頁面。

　　因此這種方式是最佳的。

　　3 特別處理的定位行集SQL查詢 這種方式是在方式2的基礎(chǔ)上針對不提供對查詢結(jié)果集行范圍定位的數(shù)據(jù)庫產(chǎn)品。

　　其在Web容器端的操作邏輯大致和方式2相同。

　　只是先要對要查詢的數(shù)據(jù)庫表要有一字段的數(shù)據(jù)能區(qū)別每條不同的數(shù)據(jù)記錄。第一次查詢時(shí)，獲得用來可唯一標(biāo)識不同記錄的字段的所有結(jié)果集，并緩存起來以備后面的分頁面查詢指定要查詢的結(jié)果集的行范圍。 主要是針對不同對查詢行集可定位范圍獲得的數(shù)據(jù)庫產(chǎn)品，如MS SQL Server等。 假設(shè)從A，B，C三個(gè)表中選取數(shù)據(jù)。且A有字段ID用來可唯一區(qū)別不同的記錄。

　　那么第一次查詢的時(shí)候，會(huì)查詢兩次1. select A.id from A,B,C where condition.

　　2. 把A的ID緩存到SESSION中?3.從Session中?，F(xiàn)可按照次序來取得相應(yīng)頁面范圍的ID來，并構(gòu)造下一個(gè)查詢語句：select A.name, B.add from A,B,C where condition && (

　　A.ID in 本頁面范圍的 ID )

　　以后每次翻頁的時(shí)候，依次獲得對應(yīng)頁的ID只要表中唯一的就可以了。無所謂大小，順序?這樣，SESSSION緩存的就只是一列而不是所有列了。當(dāng)然，對于列數(shù)不多的，效果并不好。

　　也可使用存儲(chǔ)過程實(shí)現(xiàn)，可參照：http://expert.csdn.net/Expert/topic

　　/2365/2365596.xml?temp=.7529261

　　優(yōu)點(diǎn)：

　　同方式2

　　缺點(diǎn)：

　　同方式2；

　　還要在要查詢的數(shù)據(jù)庫表中建立一個(gè)相應(yīng)的ID,用來唯一區(qū)別每條記錄。

　　結(jié)論：

　　同方式2。

　　4 緩存一次SQL查詢的結(jié)果集 優(yōu)點(diǎn)：

　　缺點(diǎn)：

　　既然我們要緩存結(jié)果，那么用戶就可能會(huì)看到過期的數(shù)據(jù)

　　

　　說明：對于實(shí)際情況的應(yīng)用來說，一般結(jié)合實(shí)際情況，結(jié)合使用方式2（或方式3）和方式4。如：一個(gè)應(yīng)用場景：對公司的產(chǎn)品的查詢是經(jīng)常的，但是產(chǎn)品的種類不是很多，這時(shí)可使用緩存方式；但是對有些查詢結(jié)果集較大，數(shù)據(jù)庫和Web容器之間的網(wǎng)絡(luò)訪問由可能是遠(yuǎn)程的，這時(shí)候可考慮使方式2（或者方式3）。

　　測試用例代碼實(shí)現(xiàn)說明

　　一：測試用例3－ServletQueryForConnPool 版本

　　1．結(jié)構(gòu)圖

　　

　　2．代碼實(shí)現(xiàn)結(jié)構(gòu)

　　3．運(yùn)行時(shí)序圖

　　4．測試運(yùn)行情況說明

　　4．1 數(shù)據(jù)庫連接和數(shù)據(jù)庫游標(biāo)占用可能比較大

　　由于數(shù)據(jù)庫的查詢及其分頁處理是直接使用JDBC的，并在分頁中是使用RseultSet的查詢結(jié)果集－游標(biāo)形式實(shí)現(xiàn)的，并且每個(gè)客戶對應(yīng)一個(gè)會(huì)話，每個(gè)會(huì)話對應(yīng)一個(gè)數(shù)據(jù)庫連接和一個(gè)結(jié)果集（游標(biāo)），數(shù)據(jù)庫連接和游標(biāo)是在會(huì)話終止時(shí)才釋放的。因此在多個(gè)客戶的請求過程中，可能對數(shù)據(jù)庫的訪問資源（數(shù)據(jù)庫連接和用于數(shù)據(jù)操作的游標(biāo)）占用比較大。

　　因此數(shù)據(jù)庫訪問及其數(shù)據(jù)庫的處理可能是個(gè)瓶頸。

　　4．2 資源沒有釋放的問題

　　會(huì)話對應(yīng)的數(shù)據(jù)庫連接和游標(biāo)可能在會(huì)話終止時(shí)沒有釋放。

　　為了更好的體現(xiàn)出使用Web容器數(shù)據(jù)庫連接池的優(yōu)點(diǎn)，應(yīng)該合理的設(shè)置連接池中連接對象的“非活動(dòng)超時(shí)時(shí)間”，建議次值和Servlet對象的會(huì)話超時(shí)時(shí)間長度一直。

　　5．此測試用例操作說明

　　5．1 部署的包的位置：

　　ServletQueryForConnPool.war

　　5．2 部署

　　1．通過Weblogic 的控制臺工具部署此包

　　2．相關(guān)的參數(shù)請看ServletQueryForConnPool.war包中的配置文件web.xml中相應(yīng)的servlet配置參數(shù)

　　5．3 測試URL

　　http://Server：port/WebAppName

　　即：

　　http://Web服務(wù)器名：端口/Servlet部署的應(yīng)用程序名

　　二：測試用例4 ServletQueryForConnPool_cache 版本

　　1．結(jié)構(gòu)圖

　　和“一：測試用例3”相同

　　2．代碼實(shí)現(xiàn)結(jié)構(gòu)

　　3．運(yùn)行時(shí)序

　　說明：使用第四種“緩存一次SQL查詢的結(jié)果集”的分頁面查詢技術(shù)，即一次SQL查詢，把從數(shù)據(jù)庫查詢出來的結(jié)果保存到會(huì)話中，以后的客戶分頁查詢操作都從此緩存中取得。

　　4．測試運(yùn)行情況說明

　　由于使用的是緩存結(jié)果集的方式，對Web容器服務(wù)器的內(nèi)存要求比較高，可能在測試過程中，Web容器服務(wù)器因內(nèi)存問題而影響整個(gè)系統(tǒng)的響應(yīng)性能。

　　5．此測試用例操作說明

　　5．1 部署的包的位置：

　　ServletQueryForConnPool_cache.war