Servlet版性能测试
主要考虑的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 优点：
这种技术是直接使用数据库产品自己提供的可对查
