主要考虑的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
（同测试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