主要考慮的Servlet版運行方式有：
一：Servlet在Web容器中的運行機制
1． 單獨一個無狀態的Servlet實例運行
即Web容器里的多個線程調用一個Servlet實例的運行方式
2． 多個Servlet實例
在Web容器中有多個Servlet實例的對象池，并有多個Web容器線程來分別調用執行
二：Servlet 連接數據庫的方式
1． 一對一
即可每個Servlet實例都有直接的數據庫連接。
具體方式有：
1> 在Servlet實例的每個處理方法中每次都調用數據庫連接，然后用此連接進行數據庫的查詢等操作，最后關閉并釋放此連接。
2> 在Servlet實例的初始化操作時就連接一個“長”的數據庫連接，直到Servlet實例在destroy時關閉并釋放此數據庫連接。
因為現在的數據庫操作主要是查詢，沒有對數據庫的增加、修改等操作，多用戶業務查詢、Web容器多線程同時對一個Servlet的同一個數據庫連接進行操作應該會沒有數據操作同步等問題。
2． 使用Web容器的數據源
這里主要是使用Web容器的數據源－數據庫連接池。
在理論上這種方式能提供最佳的性能。這是也是測試各種Web容器產品在數據庫連接池上實現的性能情況。
這里主要看Web容器的在各種應用情況下的最優化配置。
Servlet與數據源連接的實現方式：
Servlet直接從Web容器配置中取得數據源及其連接對象，然后通過此連接對象來操作數據庫。對于數據庫連接對象的管理由Web容器來管理。
三：要考慮的問題：
1． 大數據量傳輸問題
大數據量通過Servlet實例從數據庫中取得并整理后，如何有效的傳輸到客戶端IE，并且Servlet實例如何有效在Web容器中處理這些大數據量。
2． 對各種JDBC版本的測試
即不同的數據庫使用其自己專用的JDBC來連接，在性能上應該要好一些。
這里也可比較Weblogic Server中實現JDBC與各種數據庫（MSSQL、Oracle）專用的差別，從測試的結果看出Weblogic Server的技術實例以及是否真正做到了數據庫連接等處理的優化了嗎。
3． Weblogic Server的優化配置
3．1 對象池配置
包括應用邏輯處理對象的對象池化以及使用數據源時的數據庫連接對象池在各種具體應用環境下的優化配置。
3．2 線程池配置
以上兩個方面涉及到對象池化和串行化處理的策略。
3．3 Weblogic Server 的配置的各種參數的相應情況下的配置
1> JAVA VM (JAVA 虛擬機)參數在各種應用情況下的配置。
2> Weblogic Server 本身的各種參數配置。
鑒于以上的考慮對Servlet版的測試規劃為以下幾種測試用例：
序號 部署包名(*.JAR *.WAR *.EAR 等) 數據源配置 Weblogic Server
的配置 預期結果 說明 可能出現的問題和現象
1 ServletQueryForPerConn.war 在每此業務處理時創建數據庫連接，操作完畢后關閉并釋放。
通過Web.xml配置文件來配置JDBC的驅動類型和連接。 直接部署ServletQueryForPerConn.jar部署包。
Web容器中只有一個Serverlet實例。
建議配置較多的線程數量。
性能差。
在每此業務處理時創建數據庫連接，操作完畢后關閉并釋放。
此包中沒有設計到線程同步的有關代碼。 數據庫很忙（因為數據庫要接收頻繁的數據庫連接）。
可能瓶頸在數據庫對頻繁的連接處理。
數據庫事務方面：由于是在每次處理時就調用數據庫連接并查詢，因此數據庫的事務處理應該是單獨在一個獨立的處理過程中，與并行的其他線程的處理沒有關系。
2 ServletQueryForOnceConn.war Servlet對象只是的初始化時連接與數據庫的一個連接，在以后的操作中式中使用這個連接。
通過Web.xml配置文件來配置JDBC的驅動類型和連接。 直接部署ServletQueryForOnceConn.jar包；
Web容器只有一個Servlet實例。
建議配置較多的線程數量。
性能較差。
Servlet對象只是的初始化時連接與數據庫的一個連接，在以后的操作中式中使用這個連接。
此包中沒有設計到線程同步的有關代碼。 數據庫連接只有一個。
可能瓶頸在Web容器的多個線程對同一個數據庫連接對象的同步等處理（這些同步處理是Web容器自己管理的）。
可能出現查詢的數據在多個客戶請求中打亂（因為同時使用同一個數據庫通信通道）；
并且多個線程（單獨的處理單元）可能會在同一個處理事務中，可能各個處理單元會串行操作數據庫（這要看數據庫的具體實現了）。
3 ServletQueryForConnPool.war 直接使用Web容器的數據源和數據庫連接池。 配置數據源及數據庫連接池。
建議根據實際情況優化配置數據源和連接池。如可建立多個連接池等配置。 性能好。 Servlet實例不管數據庫連接，而是直接從Web容器中取得數據庫連接。數據庫的連接對象有Web容器全權管理。
此包中沒有設計到線程同步的有關代碼。 對Web容器的數據庫連接池的配置可能要根據具體情況進行有效的調整（如數據庫連接對象個數和Web容器配額的線程個數的關系等）。如果配置不佳可能是性能瓶頸在Web容器或者在數據庫方。
4 ServletQueryForConnPool.war
?。ㄍ瑴y試3） 同測試3 Web容器的數據源重新配置為數據庫產品專用的JDBC驅動器。 性能好。 測試目的是比較各種不同的JDBC數據連接驅動器的性能，以便得出根據不同的數據庫產品選擇最佳的JDBC驅動器。
只測試數據庫產品提供的專用JDBC驅動器。
（說明：因為測試3在理論上性能是最好，因此選用測試3。測試方法和測試3一樣，這樣才有可比性。） 同測試3。
5 servletQueryDS_Cache.war 同測試3 同測試3 性能一般
使用一變量來緩存查詢的數據，用戶以后的分頁查詢查詢操作是直接從此緩存中取得的。
這種方式對Web容器的內存要求高，效果不是很好，對數據量查詢小的效果可能會好些。 優點：
減少的了對數據庫訪問的次數。
缺點：
需要較大的內存。對Weblogic容器的內存要求高，對于有大量用戶的查詢操作，并且查詢的結果集較大時，可能對整個系統的性能是個很大的瓶頸。
對大量數據的分頁處理
問題描述：
背景1：一客戶通過IE請求Web服務器查詢數據，而查詢結果是上千條甚至是上萬條記錄，要求查詢結果傳送到IE客戶端并分頁顯示。
背景2：一客戶通過IE或者其他方式請求Web服務器查詢數據，而查詢結果是上千條甚至是上萬條記錄，并要求查詢結果把包傳送到客戶的E-mail中。
問：對于這樣的有大量數據的結果集，在Web服務器端如何有效的處理？
可能涉及到的問題：
1． 內存占用
大量數據的結果集，可能要
2． 傳輸速度及策略
具體的分頁處理技術
序號 名稱 處理方法 針對的數據庫 例子說明 備注
1 游標查詢 直接使用ResultSet來處理。ResultSet是直接在數據庫上建立游標，然后通過ResultSet的行位置定位接口來獲得指定行位置的記錄。
當用戶第一請求數據查詢時，就執行SQL語句查詢，獲得的ResultSet對象及其要使用的連接對象都保存到其對應的會話對象中。
以后的分頁查詢都通過第一次執行SQL獲得的ResultSet對象定位取得指定行位置的記錄。
最后在用戶不再進行分頁查詢時或會話關閉時，釋放數據庫連接和ResultSet對象等數據庫訪問資源。
說明：在用例分頁查詢的整個會話期間，一個用戶的分頁查詢就要占用一個數據庫連接對象和結果集的游標，這種方式對數據庫的訪問資源占用比較大，并且其利用率不是很高。 所有的數據庫產品。 優點：
減少了數據庫連接對象的多次分配獲取，減少了對數據庫的SQL查詢執行。
缺點：
占用數據庫訪問資源－數據庫連接對象，并占用了數據庫上的資源－游標。而這些資源都是十分寶貴的有限制的。
結論：
這種的數據庫查詢分頁處理方式不是最佳的。一般不適用這種方式。
2 定位行集SQL查詢 主要是直接使用數據庫產品的提供的對查詢的結果集可定位行范圍的SQL接口技術。
在用戶的分頁面查詢請求中，每次可取得查詢請求的行范圍的參數，然后使用這些參數生產取得指定行范圍的的SQL查詢語句，然后每次請求獲得一個數據庫連接對象并執行SQL查詢，把查詢的結果返回給用戶，最后釋放說有的數據庫訪問資源。
說明：這種方式需要每次請求時都要執行數據庫的SQL查詢語句；對數據庫的訪問資源是使用完就立即釋放，不白白占用數據庫訪問資源。 對特定（提供了對查詢結果集可定位功能的）的數據庫產品。
如：Oracle,DB2, PostgreSQL,mySQL等。(MS SQL Server 沒有提供此技術。) 如:
1． Oracle數據庫使用關鍵字：rowid或rownum
2． DB2:
rowid或rownum ()
3． PostgreSQL 使用LIMIT 和 OFFSET
4． MySQL 使用Limit 優點：
這種技術是直接使用數據庫產品自己提供的可對查詢結果集定位行范圍過濾的功能，因此直接利用了數據庫的性能對此分頁查詢的優化功能。
對數據庫的訪問資源（數據庫連接對象，數據庫游標等）沒有浪費，這些資源的充分重復的利用。
對查詢的結果對Web容器沒有什么特別要求。
缺點：
要執行多次數據庫SQL查詢操作。對每次的分頁面操作請求都要指定相應范圍的結果集來執行SQL語句的數據庫查詢操作，這對數據庫有一定的影響。
對每次分頁面查詢請求要頻繁的從Web容器中獲得數據庫訪問資源（數據庫連接對象和數據庫游標）。
要依賴于具體的數據庫產品。因為對沒有實現沒有提供此技術的數據庫產品不能使用此方式。
結論：
由于每次對數據庫的SQL查詢操作相對而言耗用的數據資源比較少，并且在實際用戶的操作中，有可能用戶對查詢的所有結果集只是需要查看其中的部分頁面。
因此這種方式是最佳的。
3 特別處理的定位行集SQL查詢 這種方式是在方式2的基礎上針對不提供對查詢結果集行范圍定位的數據庫產品。
其在Web容器端的操作邏輯大致和方式2相同。
只是先要對要查詢的數據庫表要有一字段的數據能區別每條不同的數據記錄。第一次查詢時，獲得用來可唯一標識不同記錄的字段的所有結果集，并緩存起來以備后面的分頁面查詢指定要查詢的結果集的行范圍。 主要是針對不同對查詢行集可定位范圍獲得的數據庫產品，如MS SQL Server等。 假設從A，B，C三個表中選取數據。且A有字段ID用來可唯一區別不同的記錄。
那么第一次查詢的時候，會查詢兩次1. select A.id from A,B,C where condition.
2. 把A的ID緩存到SESSION中?3.從Session中。現可按照次序來取得相應頁面范圍的ID來，并構造下一個查詢語句：select A.name, B.add from A,B,C where condition && (
A.ID in 本頁面范圍的 ID )
以后每次翻頁的時候，依次獲得對應頁的ID只要表中唯一的就可以了。無所謂大小，順序?這樣，SESSSION緩存的就只是一列而不是所有列了。當然，對于列數不多的，效果并不好。
也可使用存儲過程實現，可參照：http://expert.csdn.net/Expert/topic
/2365/2365596.xml?temp=.7529261
優點：
同方式2
缺點：
同方式2；
還要在要查詢的數據庫表中建立一個相應的ID,用來唯一區別每條記錄。
結論：
同方式2。
4 緩存一次SQL查詢的結果集 優點：
缺點：
既然我們要緩存結果，那么用戶就可能會看到過期的數據
說明：對于實際情況的應用來說，一般結合實際情況，結合使用方式2（或方式3）和方式4。如：一個應用場景：對公司的產品的查詢是經常的，但是產品的種類不是很多，這時可使用緩存方式；但是對有些查詢結果集較大，數據庫和Web容器之間的網絡訪問由可能是遠程的，這時候可考慮使方式2（或者方式3）。
測試用例代碼實現說明
一：測試用例3－ServletQueryForConnPool 版本
1．結構圖
2．代碼實現結構
3．運行時序圖
4．測試運行情況說明
4．1 數據庫連接和數據庫游標占用可能比較大
由于數據庫的查詢及其分頁處理是直接使用JDBC的，并在分頁中是使用RseultSet的查詢結果集－游標形式實現的，并且每個客戶對應一個會話，每個會話對應一個數據庫連接和一個結果集（游標），數據庫連接和游標是在會話終止時才釋放的。因此在多個客戶的請求過程中，可能對數據庫的訪問資源（數據庫連接和用于數據操作的游標）占用比較大。
因此數據庫訪問及其數據庫的處理可能是個瓶頸。
4．2 資源沒有釋放的問題
會話對應的數據庫連接和游標可能在會話終止時沒有釋放。
為了更好的體現出使用Web容器數據庫連接池的優點，應該合理的設置連接池中連接對象的“非活動超時時間”，建議次值和Servlet對象的會話超時時間長度一直。
5．此測試用例操作說明
5．1 部署的包的位置：
ServletQueryForConnPool.war
5．2 部署
1．通過Weblogic 的控制臺工具部署此包
2．相關的參數請看ServletQueryForConnPool.war包中的配置文件web.xml中相應的servlet配置參數
5．3 測試URL
http://Server：port/WebAppName
即：
http://Web服務器名：端口/Servlet部署的應用程序名
二：測試用例4 ServletQueryForConnPool_cache 版本
1．結構圖
和“一：測試用例3”相同
2．代碼實現結構
3．運行時序
說明：使用第四種“緩存一次SQL查詢的結果集”的分頁面查詢技術，即一次SQL查詢，把從數據庫查詢出來的結果保存到會話中，以后的客戶分頁查詢操作都從此緩存中取得。
4．測試運行情況說明
由于使用的是緩存結果集的方式，對Web容器服務器的內存要求比較高，可能在測試過程中，Web容器服務器因內存問題而影響整個系統的響應性能。
5．此測試用例操作說明
5．1 部署的包的位置：
ServletQueryForConnPool_cache.war