由于最近刚刚接手了一个J2EE项目（我们公司第一次应用），在技术上不是很把握，所以今天向各位请教一下，恳请帮助、批评、指正。
项目背景：某市户籍管理系统；
技术方案：J2EE；WebLogic 7+Oracle 8.17；客户端采用Web
主要问题：
1、大数据量并发操作（主要针对查询）问题。由于数据库记录为百万级，而且并发客户端为200（600*33%）左右，所以这将是影响系统性能的瓶颈。
2、WebLogic的负载平衡问题。
拟定解决方案：
针对问题1：
A、建立一个ServerFacade（Session Bean），它为多个对象提供统一获取EJB Home和获取对象的接口；
B、降低事物级别为最低；
C、对于查询操作，不采用Entity Bean，而是采用Seesion Bean+DAO的模式；
D、采用模式2的JDBC驱动，对于WebLogic 7采用JDriver与Oracle客户端连接；
E、JSP和servlet尽量和EJB部署在同一台应用服务器中，尽量少用或不用HTTP Session；
F、在WebLogic服务器设置方面，不是很熟悉，但我想这一定与性能的提升息息相关，比如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等，还请大家指导。
针对问题2：
我完全没有负载平衡应用的经验，只是知道WebLogic可以实现，但是怎么实现请大家帮忙；另外，应用负载平衡，对于程序的开发阶段有什么要求？我的意思是：这是不是系统开发后期部署阶段的问题？
本人水平有限，不知道问题说清楚没有，还恳请大家多帮忙。
20 个解决方案
#1
对于这两个问题，我的当务之急是解决大数据量的性能问题，由于自己没有这方面的开发经验而项目又很紧，所以我把自己能想到的都列举出来了，请大家帮忙判断一下。对于第二个问题，我只是有所担心对开发阶段是否有影响（估计没有），真正到具体实施时，我想自己搞不定的话可以请BEA的工程师帮忙解决。
#2
UP
#3
硬件要大大地好!
#4
继续，继续
#5
呵呵，第一个问题追加几点我的看法，查询数据时记得使用分页技术，同时不要忽略对数据库的物理存储优化，对于月统计、日统计最好在后台用job来作。
至于Weblogic的负载平衡还是找BEA工程师给你说说，我也想听听呢:-)
另外，想问一下，一天的数据量有多大（户籍管理，新增记录应当不会太多，而主要处理已经存在的用户数据吧）
至于Weblogic的负载平衡还是找BEA工程师给你说说，我也想听听呢:-)
另外，想问一下，一天的数据量有多大（户籍管理，新增记录应当不会太多，而主要处理已经存在的用户数据吧）
#6
关注！！
#7
用户数据会在一段时间内集中输入，所以系统最关键的应用是查询。
另外，关于分页，有什么好的建议么？
另外，关于分页，有什么好的建议么？
#8
UP
#9
gz
#10
我不是weblogic的人员，就我对于weblogic的负载平衡研究如下：
1.weblogic支持JNDI的集群，并且采用的是全局共享式JNDI tree
2.支持StatelessSessionBean的集群
3.StatefulSessionBean和EntityBean支持EJBHome级别的负载平衡，也就是说是在JNDI的查询时实现
3.不支持MDB的集群
4.策略比较简单，静态方法
5.支持HTTPSession的复制（JSP和Servlet的负载平衡和容错）
6.支持JMS集群
1.weblogic支持JNDI的集群，并且采用的是全局共享式JNDI tree
2.支持StatelessSessionBean的集群
3.StatefulSessionBean和EntityBean支持EJBHome级别的负载平衡，也就是说是在JNDI的查询时实现
3.不支持MDB的集群
4.策略比较简单，静态方法
5.支持HTTPSession的复制（JSP和Servlet的负载平衡和容错）
6.支持JMS集群
#11
问题1：
D:模式4是否比模式2更好呢？
D:模式4是否比模式2更好呢？
#12
分页最好在数据库级别划分数据！
#13
从速度上来讲，当然使用类型2的驱动要好，但是它需要客户端的本地代码，这就具体看环境和需求了。
分页用SQL直接表示查找某一段的数据，而不要全部取出来后再去挑选。
同时，因为你的数据相对静态，对数据库的多优化会取得更好的效果，呵呵，又重复了一遍。
分页用SQL直接表示查找某一段的数据，而不要全部取出来后再去挑选。
同时，因为你的数据相对静态，对数据库的多优化会取得更好的效果，呵呵，又重复了一遍。
#14
刚才在开发中遇到一个问题，希望大家注意：
我们的程序中用到了java.sql.Connection中的public PreparedStatement prepareStatement(String s, int i, int j)方法，但是运行后系统报错不支持。查了一下WebLogic 7的文档，发现：Jdriver不完全支持JDBC 2.0规范，包括——
Class or Interface
Unsupported Methods
java.sql.Blob
public long position(Blob blob, long l)
public long position(byte abyte0[], long l)
java.sql.CallableStatement
public Array getArray(int i)
public Date getDate(int i, Calendar calendar)
public Object getObject(int i, Map map)
public Ref getRef(int i)
public Time getTime(int i, Calendar calendar)
public Timestamp getTimestamp(int i, Calendar calendar)
public void registerOutParameter(int i, int j, String s)
java.sql.Clob
public long position(String s, long l)
public long position(java.sql.Clob clob, long l)
java.sql.Connection
public java.sql.Statement createStatement(int i, int j)
public Map getTypeMap()
public CallableStatement prepareCall(String s, int i, int j)
public PreparedStatement prepareStatement(String s, int i, int j)
public void setTypeMap(Map map)
java.sql.DatabaseMetaData
public Connection getConnection()
public ResultSet getUDTs(String s, String s1, String s2, int ai[])
public boolean supportsBatchUpdates()
java.sql.PreparedStatement
public void addBatch()
public ResultSetMetaData getMetaData()
public void setArray(int i, Array array)
public void setNull(int i, int j, String s)
public void setRef(int i, Ref ref)
java.sql.ResultSet
public boolean absolute(int i)
public void afterLast()
public void beforeFirst()
public void cancelRowUpdates()
public void deleteRow()
public boolean first()
public Array getArray(int i)
public Array getArray(String s)
public int getConcurrency()
public int getFetchDirection()
public int getFetchSize()
public Object getObject(int i, Map map)
public Object getObject(String s, Map map)
public Ref getRef(int i)
public Ref getRef(String s)
public int getRow()
public Statement getStatement()
public int getType()
public void insertRow()
java.sql.ResultSet
(continued)
public boolean isAfterLast()
public boolean isBeforeFirst()
public boolean isFirst()
public boolean isLast()
public boolean last()
public void moveToCurrentRow()
public void moveToInsertRow()
public boolean previous()
public void refreshRow()
public boolean relative(int i)
public boolean rowDeleted()
public boolean rowInserted()
public boolean rowUpdated()
public void setFetchDirection(int i)
public void setFetchSize(int i)
public void updateAsciiStream(int i, InputStream inputstream, int j)
public void updateAsciiStream(String s, InputStream inputstream, int i)
public void updateBigDecimal(int i, BigDecimal bigdecimal)
public void updateBigDecimal(String s, BigDecimal bigdecimal)
public void updateBinaryStream(int i, InputStream inputstream, int j)
public void updateBinaryStream(String s, InputStream inputstream, int i)
public void updateBoolean(int i, boolean flag)
public void updateBoolean(String s, boolean flag)
public void updateByte(int i, byte byte0)
public void updateByte(String s, byte byte0)
public void updateBytes(int i, byte abyte0[])
public void updateBytes(String s, byte abyte0[])
java.sql.ResultSet
(continued)
public void updateCharacterStream(int i, Reader reader, int j)
public void updateCharacterStream(String s, Reader reader, int i)
public void updateDate(int i, Date date)
public void updateDate(String s, Date date)
public void updateDouble(int i, double d)
public void updateDouble(String s, double d)
public void updateFloat(int i, float f)
public void updateFloat(String s, float f)
public void updateInt(int i, int j)
public void updateInt(String s, int i)
public void updateLong(int i, long l)
public void updateLong(String s, long l)
public void updateNull(int i)
public void updateNull(String s)
public void updateObject(int i, Object obj)
public void updateObject(int i, Object obj, int j)
public void updateObject(String s, Object obj)
public void updateObject(String s, Object obj, int i)
public void updateRow()
public void updateShort(int i, short word0)
public void updateShort(String s, short word0)
public void updateString(int i, String s)
public void updateString(String s, String s1)
public void updateTime(int i, Time time)
public void updateTime(String s, Time time)
public void updateTimestamp(int i, Timestamp timestamp)
public void updateTimestamp(String s, Timestamp timestamp)
java.sql.ResultSetMetaData
public String getColumnClassName(int i)
我们的程序中用到了java.sql.Connection中的public PreparedStatement prepareStatement(String s, int i, int j)方法，但是运行后系统报错不支持。查了一下WebLogic 7的文档，发现：Jdriver不完全支持JDBC 2.0规范，包括——
Class or Interface
Unsupported Methods
java.sql.Blob
public long position(Blob blob, long l)
public long position(byte abyte0[], long l)
java.sql.CallableStatement
public Array getArray(int i)
public Date getDate(int i, Calendar calendar)
public Object getObject(int i, Map map)
public Ref getRef(int i)
public Time getTime(int i, Calendar calendar)
public Timestamp getTimestamp(int i, Calendar calendar)
public void registerOutParameter(int i, int j, String s)
java.sql.Clob
public long position(String s, long l)
public long position(java.sql.Clob clob, long l)
java.sql.Connection
public java.sql.Statement createStatement(int i, int j)
public Map getTypeMap()
public CallableStatement prepareCall(String s, int i, int j)
public PreparedStatement prepareStatement(String s, int i, int j)
public void setTypeMap(Map map)
java.sql.DatabaseMetaData
public Connection getConnection()
public ResultSet getUDTs(String s, String s1, String s2, int ai[])
public boolean supportsBatchUpdates()
java.sql.PreparedStatement
public void addBatch()
public ResultSetMetaData getMetaData()
public void setArray(int i, Array array)
public void setNull(int i, int j, String s)
public void setRef(int i, Ref ref)
java.sql.ResultSet
public boolean absolute(int i)
public void afterLast()
public void beforeFirst()
public void cancelRowUpdates()
public void deleteRow()
public boolean first()
public Array getArray(int i)
public Array getArray(String s)
public int getConcurrency()
public int getFetchDirection()
public int getFetchSize()
public Object getObject(int i, Map map)
public Object getObject(String s, Map map)
public Ref getRef(int i)
public Ref getRef(String s)
public int getRow()
public Statement getStatement()
public int getType()
public void insertRow()
java.sql.ResultSet
(continued)
public boolean isAfterLast()
public boolean isBeforeFirst()
public boolean isFirst()
public boolean isLast()
public boolean last()
public void moveToCurrentRow()
public void moveToInsertRow()
public boolean previous()
public void refreshRow()
public boolean relative(int i)
public boolean rowDeleted()
public boolean rowInserted()
public boolean rowUpdated()
public void setFetchDirection(int i)
public void setFetchSize(int i)
public void updateAsciiStream(int i, InputStream inputstream, int j)
public void updateAsciiStream(String s, InputStream inputstream, int i)
public void updateBigDecimal(int i, BigDecimal bigdecimal)
public void updateBigDecimal(String s, BigDecimal bigdecimal)
public void updateBinaryStream(int i, InputStream inputstream, int j)
public void updateBinaryStream(String s, InputStream inputstream, int i)
public void updateBoolean(int i, boolean flag)
public void updateBoolean(String s, boolean flag)
public void updateByte(int i, byte byte0)
public void updateByte(String s, byte byte0)
public void updateBytes(int i, byte abyte0[])
public void updateBytes(String s, byte abyte0[])
java.sql.ResultSet
(continued)
public void updateCharacterStream(int i, Reader reader, int j)
public void updateCharacterStream(String s, Reader reader, int i)
public void updateDate(int i, Date date)
public void updateDate(String s, Date date)
public void updateDouble(int i, double d)
public void updateDouble(String s, double d)
public void updateFloat(int i, float f)
public void updateFloat(String s, float f)
public void updateInt(int i, int j)
public void updateInt(String s, int i)
public void updateLong(int i, long l)
public void updateLong(String s, long l)
public void updateNull(int i)
public void updateNull(String s)
public void updateObject(int i, Object obj)
public void updateObject(int i, Object obj, int j)
public void updateObject(String s, Object obj)
public void updateObject(String s, Object obj, int i)
public void updateRow()
public void updateShort(int i, short word0)
public void updateShort(String s, short word0)
public void updateString(int i, String s)
public void updateString(String s, String s1)
public void updateTime(int i, Time time)
public void updateTime(String s, Time time)
public void updateTimestamp(int i, Timestamp timestamp)
public void updateTimestamp(String s, Timestamp timestamp)
java.sql.ResultSetMetaData
public String getColumnClassName(int i)
#15
更换了驱动，设置如下——
Oracle JDBC的OCI8方式
属性 值
URL : jdbc:oracle:oci8:@your_tns
Driver Classes : oracle.jdbc.driver.OracleDriver
Properties (key=value): user=xixi
password=haha
dll=ocijdbc8
protocol=oci8
your_tns为你在Oracle中配置的指向oracle服务器的本地服务名（即 TNS NAME）
{取消path中的./bin/oci817_8/ (LINUX下$WL_HOME/lib/linux/ora8.1.6_oci8) LD_LIBRARY_PATH 加入 $ORACLE_HOME/lib }
startWeblogic.cmd中 Path变量加入$ORACLE_HOME/bin， CLASSPATH中加入指向$ORACLE_HOME\jdbc\lib\classes12.zip或classes111.zip
需要安装oracle的客户端 ，注意 oracle客户端配置好 oracle的环境变量 NLS_LANG和ORACLE_HOME
Oracle JDBC的OCI8方式
属性 值
URL : jdbc:oracle:oci8:@your_tns
Driver Classes : oracle.jdbc.driver.OracleDriver
Properties (key=value): user=xixi
password=haha
dll=ocijdbc8
protocol=oci8
your_tns为你在Oracle中配置的指向oracle服务器的本地服务名（即 TNS NAME）
{取消path中的./bin/oci817_8/ (LINUX下$WL_HOME/lib/linux/ora8.1.6_oci8) LD_LIBRARY_PATH 加入 $ORACLE_HOME/lib }
startWeblogic.cmd中 Path变量加入$ORACLE_HOME/bin， CLASSPATH中加入指向$ORACLE_HOME\jdbc\lib\classes12.zip或classes111.zip
需要安装oracle的客户端 ，注意 oracle客户端配置好 oracle的环境变量 NLS_LANG和ORACLE_HOME
#16
我们可以把JDBC接口按照实现的模式分为四类。有些同仁可能有这样的体会，选择不同的JDBC接口会有不同的访问速度，为何会出现这样的情况？这个问题的答案是，不同的应用需要不同模式的JDBC接口，因而我们在面对一个应用时，要慎重选择JDBC接口。
通常的DBMS都支持微软提出的ODBC规范，因而模式1可当作您在设计和实现软件时的选择，它易于配置的特性能够让你把选择JDBC等烦恼的问题暂且抛在一边，让自己的Java程序能够及早地正常工作起来。
一般说来，商业DBMS的提供者往往会为自己的数据库提供一个JDBC接口，应用的是模式4。这种模式的优势在于和数据库本身结合比较紧密，而且是纯Java的实现，在企业级的软件应用中，应该是首选。例如，对于Oracle数据库来说，有Oracle、SilverStream、DataDirect等公司提供这种类型的驱动，其性能往往被评价为最高效的、最可靠的驱动程序。但偶尔也有比较麻烦的情况，例如微软就不会提供MS SQL的JDBC接口，这时就需要到Sun的网站（http://industry.java.sun.com/products/jdbc/drivers）查找相关的模式4驱动，上面提到的DataDirect公司（http://www.datadirect-technologies.com/jdbc/jdbc.asp）就提供了支持MS SQL的模式4驱动，只是你需要支付750$购买这个JDBC驱动。
同样是纯Java实现的模式3，与模式4相比，优势在于对多种数据库的支持，体现了其灵活性。在大型的企业级的软件应用中，后台数据库往往不是一个，而且是由不同的厂商支持的。不过，模式3的JDBC驱动往往提供许多企业级的特征，例如SSL安全、支持分布式事务处理和集中管理等，因而会对你特殊的用途有很大的帮助。是否选用，还在于你对扩展应用是否有需求以及对多DBMS的支持。
谈到这儿，我对模式3和模式4作一个总结：两者都是纯Java实现的驱动，因而不需要数据库厂商提供附加的软件，就可以运行在任何标准的Java平台，性能上比较高效、可靠。
了解上述3种JDBC的实现模式之后，模式2就更容易阐释了，你可以理解它为前三者利弊平衡的妥协产物：
1 借鉴模式1利用客户机本地代码库，加速数据访问的执行，但却摒除ODBC标准，而是支持厂商自己指定的性能扩展
2 借鉴模式3利用多层结构，上层用Java实现，利于跨平台应用和支持多数据库，但下层却改为本地代码，加速执行速度
3 借鉴模式4和数据库结合紧密的优点，部分用Java实现，更是对数据库性能有很大的扩展
这种开放和高性能的特征得到了业界的肯定，因而被主要的数据库厂商强烈推荐。尽管它需要你下载本地代码库到客户机，但相对于你访问数据库速度的提高，这些应该只是举手之劳了。下面对4种实现JDBC的模式选择，归纳一下选择的顺序（当然是指你有选择余地的时候，不存在的话向后推延）：
编号 选择过程分析 选择顺序
1 实验性环境下，尽可能选择易于配置的驱动，利于Java程序的开发，后期可在对应用环境进行判断后，再对JDBC模式进行选择 1>2>3>4
2 小型企业级环境下，不需要对多数据库的支持，因而模式2和3的有些优点并不能体现出来，强烈推荐你选择模式4的JDBC驱动 4>2=3>1
3 大型企业级环境下，需要对多数据库的支持，模式2和3各有千秋，但是更多情况下是你会选择速度较快的模式2 2>3>4>1
对于不同厂商提供的但应用相同模式的JDBC接口，理论上比较不出效率的高低，你只有通过一定的工具，例如Benchmark等，对它们进行比较才能更有利于你的选择。因为暂时不存在第三方提供的数据比较结果，所以这些问题需要你对上述内容有了透彻理解之后自行解决。
通常的DBMS都支持微软提出的ODBC规范，因而模式1可当作您在设计和实现软件时的选择，它易于配置的特性能够让你把选择JDBC等烦恼的问题暂且抛在一边，让自己的Java程序能够及早地正常工作起来。
一般说来，商业DBMS的提供者往往会为自己的数据库提供一个JDBC接口，应用的是模式4。这种模式的优势在于和数据库本身结合比较紧密，而且是纯Java的实现，在企业级的软件应用中，应该是首选。例如，对于Oracle数据库来说，有Oracle、SilverStream、DataDirect等公司提供这种类型的驱动，其性能往往被评价为最高效的、最可靠的驱动程序。但偶尔也有比较麻烦的情况，例如微软就不会提供MS SQL的JDBC接口，这时就需要到Sun的网站（http://industry.java.sun.com/products/jdbc/drivers）查找相关的模式4驱动，上面提到的DataDirect公司（http://www.datadirect-technologies.com/jdbc/jdbc.asp）就提供了支持MS SQL的模式4驱动，只是你需要支付750$购买这个JDBC驱动。
同样是纯Java实现的模式3，与模式4相比，优势在于对多种数据库的支持，体现了其灵活性。在大型的企业级的软件应用中，后台数据库往往不是一个，而且是由不同的厂商支持的。不过，模式3的JDBC驱动往往提供许多企业级的特征，例如SSL安全、支持分布式事务处理和集中管理等，因而会对你特殊的用途有很大的帮助。是否选用，还在于你对扩展应用是否有需求以及对多DBMS的支持。
谈到这儿，我对模式3和模式4作一个总结：两者都是纯Java实现的驱动，因而不需要数据库厂商提供附加的软件，就可以运行在任何标准的Java平台，性能上比较高效、可靠。
了解上述3种JDBC的实现模式之后，模式2就更容易阐释了，你可以理解它为前三者利弊平衡的妥协产物：
1 借鉴模式1利用客户机本地代码库，加速数据访问的执行，但却摒除ODBC标准，而是支持厂商自己指定的性能扩展
2 借鉴模式3利用多层结构，上层用Java实现，利于跨平台应用和支持多数据库，但下层却改为本地代码，加速执行速度
3 借鉴模式4和数据库结合紧密的优点，部分用Java实现，更是对数据库性能有很大的扩展
这种开放和高性能的特征得到了业界的肯定，因而被主要的数据库厂商强烈推荐。尽管它需要你下载本地代码库到客户机，但相对于你访问数据库速度的提高，这些应该只是举手之劳了。下面对4种实现JDBC的模式选择，归纳一下选择的顺序（当然是指你有选择余地的时候，不存在的话向后推延）：
编号 选择过程分析 选择顺序
1 实验性环境下，尽可能选择易于配置的驱动，利于Java程序的开发，后期可在对应用环境进行判断后，再对JDBC模式进行选择 1>2>3>4
2 小型企业级环境下，不需要对多数据库的支持，因而模式2和3的有些优点并不能体现出来，强烈推荐你选择模式4的JDBC驱动 4>2=3>1
3 大型企业级环境下，需要对多数据库的支持，模式2和3各有千秋，但是更多情况下是你会选择速度较快的模式2 2>3>4>1
对于不同厂商提供的但应用相同模式的JDBC接口，理论上比较不出效率的高低，你只有通过一定的工具，例如Benchmark等，对它们进行比较才能更有利于你的选择。因为暂时不存在第三方提供的数据比较结果，所以这些问题需要你对上述内容有了透彻理解之后自行解决。
#17
作各记号。
#18
这里有一篇文章，讲述weblogic性能优化的，楼主看看是否有参考价值
#19
任何在市场上成功的产品都拥有良好的性能。虽然成为象WebLogic Server这样广泛使用的产品需要具备很多特性，但性能绝对是必不可少的。
良好的编程习惯在帮助应用运行方面起了很大的作用，但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植，必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因，通过调整这些“按钮”，能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分――网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。
WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如：Wily Introscope, Jprobe, Optimizelt。
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用――装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样，除非是在特殊情况下，否则在每个bean的每次交易中，至少都得有一次装载操作和一次存储操作。这些特殊情况是：
1． Bean是只读的。此时，bean只需在第一次访问时装载一次，从来不需要存储操作。当然，如果超出参数read-timeout-seconds的设置，bean将被再次装载。
2． Bean 有专门的或积极的并发策略，且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3． Bean在交易中未被修改过，此时，容器会将存储操作优化掉。
如果不属于上述任何一种情况，则code path中的每个实体bean在每次交易时，至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销，如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等,其中的某些特征是WebLogic Server 7.0新增的。
? 高速缓存：实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。
? 域分组：域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域（比方说，一幅图像）相联系，且很少被访问，则可以定义一个将此域排除在外的域组，该域组与一个查找方法相关联，这样查找时，BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。
? 并发策略：在WebLogic Server 7.0中，容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施，它的主要目的是确保实体bean所表示的数据的一致性，该一致性由bean的部署器所强制要求。无论如何，某些控制机制使得容器处理请求的速度比其它的要快一些，但这种快速是以牺牲数据的一致性为代价的。
最严格的并发策略是独占式，利用特殊主键对bean的访问是经过系列化的，因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行性。
数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。
积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。 本特征也只对EJB 2.0 适用。
只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载。
? 紧密关联缓存： 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。
除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。
缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean（SLSB），消息驱动bean（MDB）以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数（事实上，要求比此数要小）。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连（没有主键）。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。
高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。
EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作：传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活（activation）。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活（activation）。
良好的编程习惯在帮助应用运行方面起了很大的作用，但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植，必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因，通过调整这些“按钮”，能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分――网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。
WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如：Wily Introscope, Jprobe, Optimizelt。
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用――装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样，除非是在特殊情况下，否则在每个bean的每次交易中，至少都得有一次装载操作和一次存储操作。这些特殊情况是：
1． Bean是只读的。此时，bean只需在第一次访问时装载一次，从来不需要存储操作。当然，如果超出参数read-timeout-seconds的设置，bean将被再次装载。
2． Bean 有专门的或积极的并发策略，且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3． Bean在交易中未被修改过，此时，容器会将存储操作优化掉。
如果不属于上述任何一种情况，则code path中的每个实体bean在每次交易时，至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销，如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等,其中的某些特征是WebLogic Server 7.0新增的。
? 高速缓存：实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。
? 域分组：域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域（比方说，一幅图像）相联系，且很少被访问，则可以定义一个将此域排除在外的域组，该域组与一个查找方法相关联，这样查找时，BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。
? 并发策略：在WebLogic Server 7.0中，容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施，它的主要目的是确保实体bean所表示的数据的一致性，该一致性由bean的部署器所强制要求。无论如何，某些控制机制使得容器处理请求的速度比其它的要快一些，但这种快速是以牺牲数据的一致性为代价的。
最严格的并发策略是独占式，利用特殊主键对bean的访问是经过系列化的，因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行性。
数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。
积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。 本特征也只对EJB 2.0 适用。
只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载。
? 紧密关联缓存： 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。
除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。
缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean（SLSB），消息驱动bean（MDB）以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数（事实上，要求比此数要小）。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连（没有主键）。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。
高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。
EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作：传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活（activation）。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活（activation）。
#20
JDBC
对数据库的访问来说，调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小――连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现，则连接数应为执行队列中的线程数，比读取socket的线程（缺省执行队列中用来读取进入请求的线程）数要少。为了避免在运行期间对连接进行创建和删除，可在初始时即将连接池设置为其最大容量。如果可能的话，应确保参数TestConnectionsOnReserve被设置为假（false，这是缺省设置）。如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接。
另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存，大小由JDBC连接池配置时指定。缓存是静态的，时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话，则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能，但也不能盲目使用它。如果数据库的格式有了变化，那么在不重新启动服务器的情况下，无法使缓存中的语句失效或者是用新的进行替换。当然，缓存中的语句会使数据库中的光标得以保留。
对于WebLogic Server 7.0来说，由于jDriver性能的改进已使其速度远远快于Oracle的廋驱动程序，尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明（http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance）。
JMS
JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此，JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”，反过来也不会抢夺其它应用的资源。对JMS来说，大多数的调试参数都是在服务的质量上进行折衷处理。如，利用文件式持续性目的地（file-persistent destnation）禁止同步写操作（通过设置特性： －Dweblogic.JMSFileStore.SynchronousWritesEnabled =false）以后会引起性能急剧提高，但同时也会冒着丢失消息或者重复接收消息的风险。类似地，利用多点传送发送消息会提升性能，同时也会有消息半途丢失的危险。
消息确认间隔不应设置得过短――发送确认的比率越大，处理消息的速度可能会越慢。同时，如果设置得过大，则意味着系统发生故障时，消息会丢失或者被重复发送。
一般说来，应在单个服务器上对多个JMS目的地进行配置，而不是将它们分散在多个JMS服务器，除非不再需要扩展。
关闭消息页面调度（paging）可能会提高性能，但会影响可扩展性。如果打开消息页面调度（paging），则需要额外的I/O操作以便将消息串行化到硬盘，在必要的时候再读进来，但同时也降低了对内存的要求。
一般来说，异步过程比同步过程更好操作，更易于调节。
Web容器
Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据，然后使用servlet和JSP生成动态内容，其中应用层一般由EJB组成。在这种结构中，servlet 和JSP保留对EJB的引用，以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上，则利用JNDI进行查询的费用是很昂贵的。
JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容，对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化，则可以通过将ServletReloadCheckSecs 设置为－1，从而关闭自动装载（auto-reloading）功能。使用这种方法以后，服务器将不再轮询Web层是否有变化，如果JSP和servlet的数量很多，则效果是非常明显的。
这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的，可以考虑使用有状态会话bean来替代。
JVM调试
如今的大多数JVM具有自主调节功能，因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间，按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收（GC）处理。在这种设置环境中，如果堆太大的话，垃圾回收的间隔应设为一分钟或更长。最后，需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考：
http://edocs.bea.com/wls/docs70/perform/JVMTuning.html1104200。
服务器调试
除了由各个子系统提供的调试参数以外，还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效，仅当下列情况成立时再考虑使用这种方法：预定的吞吐量没有达到；等待队列（未开始处理的请求）过长；CPU仍有剩余。当然，这样做并不一定能改善性能。CPU使用率低可能是由于对服务器的其它资源竞争所致，如，没有足够的JDBC连接。当改变线程数时应考虑到这些类似的因素。
在WebLogic Server 7.0中，提供了配置多个执行队列的功能，并且能够在部署中定义处理特殊的EJB或JSP/servlet请求的执行队列。要做到这些，只要在运行weblogic.ejbc时将标志 －dispatchPolicy <队列名称> 传送给bean 即可。对于JSP/servlet，可将设置Web应用的weblogic部署描述符中初始化参数（init-param） wl-dispatch-policy的值设为执行队列的名字即可。有时应用中的某些bean/JSP对操作的响应时间比其它的要长，此时，可以对这些bean/JSP设置单独的执行队列。至于队列的大小，要达到最好的性能，还取决于经验。
另一个比较大的问题是决定在何种情况下应该使用WebLogic性能包（http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html - 1112119）。如果socket数不太多（每个服务器上都有一个socket用于客户端JVM的远程方法调用连接），而且总是忙于读取从客户端发送过来的请求数据，那么此时使用性能包恐怕不会有明显的改进。也有可能不用性能包会导致相似或更好的结果，这取决于JVM在处理网络I/O时的具体实现。
Socket读取线程取自缺省执行队列。在Windows 环境下，每个CPU有两个socket读取线程，在solaris环境下，共有三个socket用于本地输入输出(native I/O)。对于Java 输入输出（I/O），读取线程数由配置文件config.xml中的参数PercentSocketReaderThreads 进行设置。它的缺省值是33%, 上限是50%，这是显而易见的，因为如果没有线程用于处理请求，则同样不会有更多的读取线程啦。对于Java I/O，应使读取线程数尽量接近客户端连接数，因为在等待请求时，Java I/O会阻塞。这也是为什么当客户端的连接数增加时，线程数不能一直同等增加的原因。
结论
我们上面只讨论了调试服务器的部分方法。需要记住的是，一个设计蹩脚，编写欠佳的应用，通常都不会有好的性能表现，无论对服务器及其参数如何调试。贯穿应用开发周期的各个阶段――从设计到部署，性能始终应该是考虑的关键因素。经常发生的情况是性能被放在了功能之后，等到发现了问题再去修改，已经很困难了。有关WebLogic Server 性能调试的其它信息可以参考：http://e-docs.bea.com/wls/docs70/perform/index.html。
对数据库的访问来说，调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小――连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现，则连接数应为执行队列中的线程数，比读取socket的线程（缺省执行队列中用来读取进入请求的线程）数要少。为了避免在运行期间对连接进行创建和删除，可在初始时即将连接池设置为其最大容量。如果可能的话，应确保参数TestConnectionsOnReserve被设置为假（false，这是缺省设置）。如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接。
另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存，大小由JDBC连接池配置时指定。缓存是静态的，时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话，则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能，但也不能盲目使用它。如果数据库的格式有了变化，那么在不重新启动服务器的情况下，无法使缓存中的语句失效或者是用新的进行替换。当然，缓存中的语句会使数据库中的光标得以保留。
对于WebLogic Server 7.0来说，由于jDriver性能的改进已使其速度远远快于Oracle的廋驱动程序，尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明（http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance）。
JMS
JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此，JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”，反过来也不会抢夺其它应用的资源。对JMS来说，大多数的调试参数都是在服务的质量上进行折衷处理。如，利用文件式持续性目的地（file-persistent destnation）禁止同步写操作（通过设置特性： －Dweblogic.JMSFileStore.SynchronousWritesEnabled =false）以后会引起性能急剧提高，但同时也会冒着丢失消息或者重复接收消息的风险。类似地，利用多点传送发送消息会提升性能，同时也会有消息半途丢失的危险。
消息确认间隔不应设置得过短――发送确认的比率越大，处理消息的速度可能会越慢。同时，如果设置得过大，则意味着系统发生故障时，消息会丢失或者被重复发送。
一般说来，应在单个服务器上对多个JMS目的地进行配置，而不是将它们分散在多个JMS服务器，除非不再需要扩展。
关闭消息页面调度（paging）可能会提高性能，但会影响可扩展性。如果打开消息页面调度（paging），则需要额外的I/O操作以便将消息串行化到硬盘，在必要的时候再读进来，但同时也降低了对内存的要求。
一般来说，异步过程比同步过程更好操作，更易于调节。
Web容器
Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据，然后使用servlet和JSP生成动态内容，其中应用层一般由EJB组成。在这种结构中，servlet 和JSP保留对EJB的引用，以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上，则利用JNDI进行查询的费用是很昂贵的。
JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容，对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化，则可以通过将ServletReloadCheckSecs 设置为－1，从而关闭自动装载（auto-reloading）功能。使用这种方法以后，服务器将不再轮询Web层是否有变化，如果JSP和servlet的数量很多，则效果是非常明显的。
这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的，可以考虑使用有状态会话bean来替代。
JVM调试
如今的大多数JVM具有自主调节功能，因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间，按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收（GC）处理。在这种设置环境中，如果堆太大的话，垃圾回收的间隔应设为一分钟或更长。最后，需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考：
http://edocs.bea.com/wls/docs70/perform/JVMTuning.html1104200。
服务器调试
除了由各个子系统提供的调试参数以外，还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效，仅当下列情况成立时再考虑使用这种方法：预定的吞吐量没有达到；等待队列（未开始处理的请求）过长；CPU仍有剩余。当然，这样做并不一定能改善性能。CPU使用率低可能是由于对服务器的其它资源竞争所致，如，没有足够的JDBC连接。当改变线程数时应考虑到这些类似的因素。
在WebLogic Server 7.0中，提供了配置多个执行队列的功能，并且能够在部署中定义处理特殊的EJB或JSP/servlet请求的执行队列。要做到这些，只要在运行weblogic.ejbc时将标志 －dispatchPolicy <队列名称> 传送给bean 即可。对于JSP/servlet，可将设置Web应用的weblogic部署描述符中初始化参数（init-param） wl-dispatch-policy的值设为执行队列的名字即可。有时应用中的某些bean/JSP对操作的响应时间比其它的要长，此时，可以对这些bean/JSP设置单独的执行队列。至于队列的大小，要达到最好的性能，还取决于经验。
另一个比较大的问题是决定在何种情况下应该使用WebLogic性能包（http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html - 1112119）。如果socket数不太多（每个服务器上都有一个socket用于客户端JVM的远程方法调用连接），而且总是忙于读取从客户端发送过来的请求数据，那么此时使用性能包恐怕不会有明显的改进。也有可能不用性能包会导致相似或更好的结果，这取决于JVM在处理网络I/O时的具体实现。
Socket读取线程取自缺省执行队列。在Windows 环境下，每个CPU有两个socket读取线程，在solaris环境下，共有三个socket用于本地输入输出(native I/O)。对于Java 输入输出（I/O），读取线程数由配置文件config.xml中的参数PercentSocketReaderThreads 进行设置。它的缺省值是33%, 上限是50%，这是显而易见的，因为如果没有线程用于处理请求，则同样不会有更多的读取线程啦。对于Java I/O，应使读取线程数尽量接近客户端连接数，因为在等待请求时，Java I/O会阻塞。这也是为什么当客户端的连接数增加时，线程数不能一直同等增加的原因。
结论
我们上面只讨论了调试服务器的部分方法。需要记住的是，一个设计蹩脚，编写欠佳的应用，通常都不会有好的性能表现，无论对服务器及其参数如何调试。贯穿应用开发周期的各个阶段――从设计到部署，性能始终应该是考虑的关键因素。经常发生的情况是性能被放在了功能之后，等到发现了问题再去修改，已经很困难了。有关WebLogic Server 性能调试的其它信息可以参考：http://e-docs.bea.com/wls/docs70/perform/index.html。
#1
对于这两个问题，我的当务之急是解决大数据量的性能问题，由于自己没有这方面的开发经验而项目又很紧，所以我把自己能想到的都列举出来了，请大家帮忙判断一下。对于第二个问题，我只是有所担心对开发阶段是否有影响（估计没有），真正到具体实施时，我想自己搞不定的话可以请BEA的工程师帮忙解决。
#2
UP
#3
硬件要大大地好!
#4
继续，继续
#5
呵呵，第一个问题追加几点我的看法，查询数据时记得使用分页技术，同时不要忽略对数据库的物理存储优化，对于月统计、日统计最好在后台用job来作。
至于Weblogic的负载平衡还是找BEA工程师给你说说，我也想听听呢:-)
另外，想问一下，一天的数据量有多大（户籍管理，新增记录应当不会太多，而主要处理已经存在的用户数据吧）
至于Weblogic的负载平衡还是找BEA工程师给你说说，我也想听听呢:-)
另外，想问一下，一天的数据量有多大（户籍管理，新增记录应当不会太多，而主要处理已经存在的用户数据吧）
#6
关注！！
#7
用户数据会在一段时间内集中输入，所以系统最关键的应用是查询。
另外，关于分页，有什么好的建议么？
另外，关于分页，有什么好的建议么？
#8
UP
#9
gz
#10
我不是weblogic的人员，就我对于weblogic的负载平衡研究如下：
1.weblogic支持JNDI的集群，并且采用的是全局共享式JNDI tree
2.支持StatelessSessionBean的集群
3.StatefulSessionBean和EntityBean支持EJBHome级别的负载平衡，也就是说是在JNDI的查询时实现
3.不支持MDB的集群
4.策略比较简单，静态方法
5.支持HTTPSession的复制（JSP和Servlet的负载平衡和容错）
6.支持JMS集群
1.weblogic支持JNDI的集群，并且采用的是全局共享式JNDI tree
2.支持StatelessSessionBean的集群
3.StatefulSessionBean和EntityBean支持EJBHome级别的负载平衡，也就是说是在JNDI的查询时实现
3.不支持MDB的集群
4.策略比较简单，静态方法
5.支持HTTPSession的复制（JSP和Servlet的负载平衡和容错）
6.支持JMS集群
#11
问题1：
D:模式4是否比模式2更好呢？
D:模式4是否比模式2更好呢？
#12
分页最好在数据库级别划分数据！
#13
从速度上来讲，当然使用类型2的驱动要好，但是它需要客户端的本地代码，这就具体看环境和需求了。
分页用SQL直接表示查找某一段的数据，而不要全部取出来后再去挑选。
同时，因为你的数据相对静态，对数据库的多优化会取得更好的效果，呵呵，又重复了一遍。
分页用SQL直接表示查找某一段的数据，而不要全部取出来后再去挑选。
同时，因为你的数据相对静态，对数据库的多优化会取得更好的效果，呵呵，又重复了一遍。
#14
刚才在开发中遇到一个问题，希望大家注意：
我们的程序中用到了java.sql.Connection中的public PreparedStatement prepareStatement(String s, int i, int j)方法，但是运行后系统报错不支持。查了一下WebLogic 7的文档，发现：Jdriver不完全支持JDBC 2.0规范，包括——
Class or Interface
Unsupported Methods
java.sql.Blob
public long position(Blob blob, long l)
public long position(byte abyte0[], long l)
java.sql.CallableStatement
public Array getArray(int i)
public Date getDate(int i, Calendar calendar)
public Object getObject(int i, Map map)
public Ref getRef(int i)
public Time getTime(int i, Calendar calendar)
public Timestamp getTimestamp(int i, Calendar calendar)
public void registerOutParameter(int i, int j, String s)
java.sql.Clob
public long position(String s, long l)
public long position(java.sql.Clob clob, long l)
java.sql.Connection
public java.sql.Statement createStatement(int i, int j)
public Map getTypeMap()
public CallableStatement prepareCall(String s, int i, int j)
public PreparedStatement prepareStatement(String s, int i, int j)
public void setTypeMap(Map map)
java.sql.DatabaseMetaData
public Connection getConnection()
public ResultSet getUDTs(String s, String s1, String s2, int ai[])
public boolean supportsBatchUpdates()
java.sql.PreparedStatement
public void addBatch()
public ResultSetMetaData getMetaData()
public void setArray(int i, Array array)
public void setNull(int i, int j, String s)
public void setRef(int i, Ref ref)
java.sql.ResultSet
public boolean absolute(int i)
public void afterLast()
public void beforeFirst()
public void cancelRowUpdates()
public void deleteRow()
public boolean first()
public Array getArray(int i)
public Array getArray(String s)
public int getConcurrency()
public int getFetchDirection()
public int getFetchSize()
public Object getObject(int i, Map map)
public Object getObject(String s, Map map)
public Ref getRef(int i)
public Ref getRef(String s)
public int getRow()
public Statement getStatement()
public int getType()
public void insertRow()
java.sql.ResultSet
(continued)
public boolean isAfterLast()
public boolean isBeforeFirst()
public boolean isFirst()
public boolean isLast()
public boolean last()
public void moveToCurrentRow()
public void moveToInsertRow()
public boolean previous()
public void refreshRow()
public boolean relative(int i)
public boolean rowDeleted()
public boolean rowInserted()
public boolean rowUpdated()
public void setFetchDirection(int i)
public void setFetchSize(int i)
public void updateAsciiStream(int i, InputStream inputstream, int j)
public void updateAsciiStream(String s, InputStream inputstream, int i)
public void updateBigDecimal(int i, BigDecimal bigdecimal)
public void updateBigDecimal(String s, BigDecimal bigdecimal)
public void updateBinaryStream(int i, InputStream inputstream, int j)
public void updateBinaryStream(String s, InputStream inputstream, int i)
public void updateBoolean(int i, boolean flag)
public void updateBoolean(String s, boolean flag)
public void updateByte(int i, byte byte0)
public void updateByte(String s, byte byte0)
public void updateBytes(int i, byte abyte0[])
public void updateBytes(String s, byte abyte0[])
java.sql.ResultSet
(continued)
public void updateCharacterStream(int i, Reader reader, int j)
public void updateCharacterStream(String s, Reader reader, int i)
public void updateDate(int i, Date date)
public void updateDate(String s, Date date)
public void updateDouble(int i, double d)
public void updateDouble(String s, double d)
public void updateFloat(int i, float f)
public void updateFloat(String s, float f)
public void updateInt(int i, int j)
public void updateInt(String s, int i)
public void updateLong(int i, long l)
public void updateLong(String s, long l)
public void updateNull(int i)
public void updateNull(String s)
public void updateObject(int i, Object obj)
public void updateObject(int i, Object obj, int j)
public void updateObject(String s, Object obj)
public void updateObject(String s, Object obj, int i)
public void updateRow()
public void updateShort(int i, short word0)
public void updateShort(String s, short word0)
public void updateString(int i, String s)
public void updateString(String s, String s1)
public void updateTime(int i, Time time)
public void updateTime(String s, Time time)
public void updateTimestamp(int i, Timestamp timestamp)
public void updateTimestamp(String s, Timestamp timestamp)
java.sql.ResultSetMetaData
public String getColumnClassName(int i)
我们的程序中用到了java.sql.Connection中的public PreparedStatement prepareStatement(String s, int i, int j)方法，但是运行后系统报错不支持。查了一下WebLogic 7的文档，发现：Jdriver不完全支持JDBC 2.0规范，包括——
Class or Interface
Unsupported Methods
java.sql.Blob
public long position(Blob blob, long l)
public long position(byte abyte0[], long l)
java.sql.CallableStatement
public Array getArray(int i)
public Date getDate(int i, Calendar calendar)
public Object getObject(int i, Map map)
public Ref getRef(int i)
public Time getTime(int i, Calendar calendar)
public Timestamp getTimestamp(int i, Calendar calendar)
public void registerOutParameter(int i, int j, String s)
java.sql.Clob
public long position(String s, long l)
public long position(java.sql.Clob clob, long l)
java.sql.Connection
public java.sql.Statement createStatement(int i, int j)
public Map getTypeMap()
public CallableStatement prepareCall(String s, int i, int j)
public PreparedStatement prepareStatement(String s, int i, int j)
public void setTypeMap(Map map)
java.sql.DatabaseMetaData
public Connection getConnection()
public ResultSet getUDTs(String s, String s1, String s2, int ai[])
public boolean supportsBatchUpdates()
java.sql.PreparedStatement
public void addBatch()
public ResultSetMetaData getMetaData()
public void setArray(int i, Array array)
public void setNull(int i, int j, String s)
public void setRef(int i, Ref ref)
java.sql.ResultSet
public boolean absolute(int i)
public void afterLast()
public void beforeFirst()
public void cancelRowUpdates()
public void deleteRow()
public boolean first()
public Array getArray(int i)
public Array getArray(String s)
public int getConcurrency()
public int getFetchDirection()
public int getFetchSize()
public Object getObject(int i, Map map)
public Object getObject(String s, Map map)
public Ref getRef(int i)
public Ref getRef(String s)
public int getRow()
public Statement getStatement()
public int getType()
public void insertRow()
java.sql.ResultSet
(continued)
public boolean isAfterLast()
public boolean isBeforeFirst()
public boolean isFirst()
public boolean isLast()
public boolean last()
public void moveToCurrentRow()
public void moveToInsertRow()
public boolean previous()
public void refreshRow()
public boolean relative(int i)
public boolean rowDeleted()
public boolean rowInserted()
public boolean rowUpdated()
public void setFetchDirection(int i)
public void setFetchSize(int i)
public void updateAsciiStream(int i, InputStream inputstream, int j)
public void updateAsciiStream(String s, InputStream inputstream, int i)
public void updateBigDecimal(int i, BigDecimal bigdecimal)
public void updateBigDecimal(String s, BigDecimal bigdecimal)
public void updateBinaryStream(int i, InputStream inputstream, int j)
public void updateBinaryStream(String s, InputStream inputstream, int i)
public void updateBoolean(int i, boolean flag)
public void updateBoolean(String s, boolean flag)
public void updateByte(int i, byte byte0)
public void updateByte(String s, byte byte0)
public void updateBytes(int i, byte abyte0[])
public void updateBytes(String s, byte abyte0[])
java.sql.ResultSet
(continued)
public void updateCharacterStream(int i, Reader reader, int j)
public void updateCharacterStream(String s, Reader reader, int i)
public void updateDate(int i, Date date)
public void updateDate(String s, Date date)
public void updateDouble(int i, double d)
public void updateDouble(String s, double d)
public void updateFloat(int i, float f)
public void updateFloat(String s, float f)
public void updateInt(int i, int j)
public void updateInt(String s, int i)
public void updateLong(int i, long l)
public void updateLong(String s, long l)
public void updateNull(int i)
public void updateNull(String s)
public void updateObject(int i, Object obj)
public void updateObject(int i, Object obj, int j)
public void updateObject(String s, Object obj)
public void updateObject(String s, Object obj, int i)
public void updateRow()
public void updateShort(int i, short word0)
public void updateShort(String s, short word0)
public void updateString(int i, String s)
public void updateString(String s, String s1)
public void updateTime(int i, Time time)
public void updateTime(String s, Time time)
public void updateTimestamp(int i, Timestamp timestamp)
public void updateTimestamp(String s, Timestamp timestamp)
java.sql.ResultSetMetaData
public String getColumnClassName(int i)
#15
更换了驱动，设置如下——
Oracle JDBC的OCI8方式
属性 值
URL : jdbc:oracle:oci8:@your_tns
Driver Classes : oracle.jdbc.driver.OracleDriver
Properties (key=value): user=xixi
password=haha
dll=ocijdbc8
protocol=oci8
your_tns为你在Oracle中配置的指向oracle服务器的本地服务名（即 TNS NAME）
{取消path中的./bin/oci817_8/ (LINUX下$WL_HOME/lib/linux/ora8.1.6_oci8) LD_LIBRARY_PATH 加入 $ORACLE_HOME/lib }
startWeblogic.cmd中 Path变量加入$ORACLE_HOME/bin， CLASSPATH中加入指向$ORACLE_HOME\jdbc\lib\classes12.zip或classes111.zip
需要安装oracle的客户端 ，注意 oracle客户端配置好 oracle的环境变量 NLS_LANG和ORACLE_HOME
Oracle JDBC的OCI8方式
属性 值
URL : jdbc:oracle:oci8:@your_tns
Driver Classes : oracle.jdbc.driver.OracleDriver
Properties (key=value): user=xixi
password=haha
dll=ocijdbc8
protocol=oci8
your_tns为你在Oracle中配置的指向oracle服务器的本地服务名（即 TNS NAME）
{取消path中的./bin/oci817_8/ (LINUX下$WL_HOME/lib/linux/ora8.1.6_oci8) LD_LIBRARY_PATH 加入 $ORACLE_HOME/lib }
startWeblogic.cmd中 Path变量加入$ORACLE_HOME/bin， CLASSPATH中加入指向$ORACLE_HOME\jdbc\lib\classes12.zip或classes111.zip
需要安装oracle的客户端 ，注意 oracle客户端配置好 oracle的环境变量 NLS_LANG和ORACLE_HOME
#16
我们可以把JDBC接口按照实现的模式分为四类。有些同仁可能有这样的体会，选择不同的JDBC接口会有不同的访问速度，为何会出现这样的情况？这个问题的答案是，不同的应用需要不同模式的JDBC接口，因而我们在面对一个应用时，要慎重选择JDBC接口。
通常的DBMS都支持微软提出的ODBC规范，因而模式1可当作您在设计和实现软件时的选择，它易于配置的特性能够让你把选择JDBC等烦恼的问题暂且抛在一边，让自己的Java程序能够及早地正常工作起来。
一般说来，商业DBMS的提供者往往会为自己的数据库提供一个JDBC接口，应用的是模式4。这种模式的优势在于和数据库本身结合比较紧密，而且是纯Java的实现，在企业级的软件应用中，应该是首选。例如，对于Oracle数据库来说，有Oracle、SilverStream、DataDirect等公司提供这种类型的驱动，其性能往往被评价为最高效的、最可靠的驱动程序。但偶尔也有比较麻烦的情况，例如微软就不会提供MS SQL的JDBC接口，这时就需要到Sun的网站（http://industry.java.sun.com/products/jdbc/drivers）查找相关的模式4驱动，上面提到的DataDirect公司（http://www.datadirect-technologies.com/jdbc/jdbc.asp）就提供了支持MS SQL的模式4驱动，只是你需要支付750$购买这个JDBC驱动。
同样是纯Java实现的模式3，与模式4相比，优势在于对多种数据库的支持，体现了其灵活性。在大型的企业级的软件应用中，后台数据库往往不是一个，而且是由不同的厂商支持的。不过，模式3的JDBC驱动往往提供许多企业级的特征，例如SSL安全、支持分布式事务处理和集中管理等，因而会对你特殊的用途有很大的帮助。是否选用，还在于你对扩展应用是否有需求以及对多DBMS的支持。
谈到这儿，我对模式3和模式4作一个总结：两者都是纯Java实现的驱动，因而不需要数据库厂商提供附加的软件，就可以运行在任何标准的Java平台，性能上比较高效、可靠。
了解上述3种JDBC的实现模式之后，模式2就更容易阐释了，你可以理解它为前三者利弊平衡的妥协产物：
1 借鉴模式1利用客户机本地代码库，加速数据访问的执行，但却摒除ODBC标准，而是支持厂商自己指定的性能扩展
2 借鉴模式3利用多层结构，上层用Java实现，利于跨平台应用和支持多数据库，但下层却改为本地代码，加速执行速度
3 借鉴模式4和数据库结合紧密的优点，部分用Java实现，更是对数据库性能有很大的扩展
这种开放和高性能的特征得到了业界的肯定，因而被主要的数据库厂商强烈推荐。尽管它需要你下载本地代码库到客户机，但相对于你访问数据库速度的提高，这些应该只是举手之劳了。下面对4种实现JDBC的模式选择，归纳一下选择的顺序（当然是指你有选择余地的时候，不存在的话向后推延）：
编号 选择过程分析 选择顺序
1 实验性环境下，尽可能选择易于配置的驱动，利于Java程序的开发，后期可在对应用环境进行判断后，再对JDBC模式进行选择 1>2>3>4
2 小型企业级环境下，不需要对多数据库的支持，因而模式2和3的有些优点并不能体现出来，强烈推荐你选择模式4的JDBC驱动 4>2=3>1
3 大型企业级环境下，需要对多数据库的支持，模式2和3各有千秋，但是更多情况下是你会选择速度较快的模式2 2>3>4>1
对于不同厂商提供的但应用相同模式的JDBC接口，理论上比较不出效率的高低，你只有通过一定的工具，例如Benchmark等，对它们进行比较才能更有利于你的选择。因为暂时不存在第三方提供的数据比较结果，所以这些问题需要你对上述内容有了透彻理解之后自行解决。
通常的DBMS都支持微软提出的ODBC规范，因而模式1可当作您在设计和实现软件时的选择，它易于配置的特性能够让你把选择JDBC等烦恼的问题暂且抛在一边，让自己的Java程序能够及早地正常工作起来。
一般说来，商业DBMS的提供者往往会为自己的数据库提供一个JDBC接口，应用的是模式4。这种模式的优势在于和数据库本身结合比较紧密，而且是纯Java的实现，在企业级的软件应用中，应该是首选。例如，对于Oracle数据库来说，有Oracle、SilverStream、DataDirect等公司提供这种类型的驱动，其性能往往被评价为最高效的、最可靠的驱动程序。但偶尔也有比较麻烦的情况，例如微软就不会提供MS SQL的JDBC接口，这时就需要到Sun的网站（http://industry.java.sun.com/products/jdbc/drivers）查找相关的模式4驱动，上面提到的DataDirect公司（http://www.datadirect-technologies.com/jdbc/jdbc.asp）就提供了支持MS SQL的模式4驱动，只是你需要支付750$购买这个JDBC驱动。
同样是纯Java实现的模式3，与模式4相比，优势在于对多种数据库的支持，体现了其灵活性。在大型的企业级的软件应用中，后台数据库往往不是一个，而且是由不同的厂商支持的。不过，模式3的JDBC驱动往往提供许多企业级的特征，例如SSL安全、支持分布式事务处理和集中管理等，因而会对你特殊的用途有很大的帮助。是否选用，还在于你对扩展应用是否有需求以及对多DBMS的支持。
谈到这儿，我对模式3和模式4作一个总结：两者都是纯Java实现的驱动，因而不需要数据库厂商提供附加的软件，就可以运行在任何标准的Java平台，性能上比较高效、可靠。
了解上述3种JDBC的实现模式之后，模式2就更容易阐释了，你可以理解它为前三者利弊平衡的妥协产物：
1 借鉴模式1利用客户机本地代码库，加速数据访问的执行，但却摒除ODBC标准，而是支持厂商自己指定的性能扩展
2 借鉴模式3利用多层结构，上层用Java实现，利于跨平台应用和支持多数据库，但下层却改为本地代码，加速执行速度
3 借鉴模式4和数据库结合紧密的优点，部分用Java实现，更是对数据库性能有很大的扩展
这种开放和高性能的特征得到了业界的肯定，因而被主要的数据库厂商强烈推荐。尽管它需要你下载本地代码库到客户机，但相对于你访问数据库速度的提高，这些应该只是举手之劳了。下面对4种实现JDBC的模式选择，归纳一下选择的顺序（当然是指你有选择余地的时候，不存在的话向后推延）：
编号 选择过程分析 选择顺序
1 实验性环境下，尽可能选择易于配置的驱动，利于Java程序的开发，后期可在对应用环境进行判断后，再对JDBC模式进行选择 1>2>3>4
2 小型企业级环境下，不需要对多数据库的支持，因而模式2和3的有些优点并不能体现出来，强烈推荐你选择模式4的JDBC驱动 4>2=3>1
3 大型企业级环境下，需要对多数据库的支持，模式2和3各有千秋，但是更多情况下是你会选择速度较快的模式2 2>3>4>1
对于不同厂商提供的但应用相同模式的JDBC接口，理论上比较不出效率的高低，你只有通过一定的工具，例如Benchmark等，对它们进行比较才能更有利于你的选择。因为暂时不存在第三方提供的数据比较结果，所以这些问题需要你对上述内容有了透彻理解之后自行解决。
#17
作各记号。
#18
这里有一篇文章，讲述weblogic性能优化的，楼主看看是否有参考价值
#19
任何在市场上成功的产品都拥有良好的性能。虽然成为象WebLogic Server这样广泛使用的产品需要具备很多特性，但性能绝对是必不可少的。
良好的编程习惯在帮助应用运行方面起了很大的作用，但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植，必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因，通过调整这些“按钮”，能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分――网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。
WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如：Wily Introscope, Jprobe, Optimizelt。
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用――装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样，除非是在特殊情况下，否则在每个bean的每次交易中，至少都得有一次装载操作和一次存储操作。这些特殊情况是：
1． Bean是只读的。此时，bean只需在第一次访问时装载一次，从来不需要存储操作。当然，如果超出参数read-timeout-seconds的设置，bean将被再次装载。
2． Bean 有专门的或积极的并发策略，且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3． Bean在交易中未被修改过，此时，容器会将存储操作优化掉。
如果不属于上述任何一种情况，则code path中的每个实体bean在每次交易时，至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销，如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等,其中的某些特征是WebLogic Server 7.0新增的。
? 高速缓存：实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。
? 域分组：域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域（比方说，一幅图像）相联系，且很少被访问，则可以定义一个将此域排除在外的域组，该域组与一个查找方法相关联，这样查找时，BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。
? 并发策略：在WebLogic Server 7.0中，容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施，它的主要目的是确保实体bean所表示的数据的一致性，该一致性由bean的部署器所强制要求。无论如何，某些控制机制使得容器处理请求的速度比其它的要快一些，但这种快速是以牺牲数据的一致性为代价的。
最严格的并发策略是独占式，利用特殊主键对bean的访问是经过系列化的，因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行性。
数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。
积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。 本特征也只对EJB 2.0 适用。
只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载。
? 紧密关联缓存： 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。
除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。
缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean（SLSB），消息驱动bean（MDB）以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数（事实上，要求比此数要小）。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连（没有主键）。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。
高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。
EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作：传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活（activation）。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活（activation）。
良好的编程习惯在帮助应用运行方面起了很大的作用，但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植，必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因，通过调整这些“按钮”，能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数，不过并未将所有可调整的属性全部列出。此外，在将此处推荐的方法运用到产品环境之前，建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分――网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题，调试错了组件可能会使情况更糟。
WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合，用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况，这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器，如：Wily Introscope, Jprobe, Optimizelt。
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用――装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样，除非是在特殊情况下，否则在每个bean的每次交易中，至少都得有一次装载操作和一次存储操作。这些特殊情况是：
1． Bean是只读的。此时，bean只需在第一次访问时装载一次，从来不需要存储操作。当然，如果超出参数read-timeout-seconds的设置，bean将被再次装载。
2． Bean 有专门的或积极的并发策略，且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3． Bean在交易中未被修改过，此时，容器会将存储操作优化掉。
如果不属于上述任何一种情况，则code path中的每个实体bean在每次交易时，至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销，如：高速缓存技术、域（field）分组、并发策略以及紧密关联缓存（eager relationship caching）等,其中的某些特征是WebLogic Server 7.0新增的。
? 高速缓存：实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。
? 域分组：域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域（比方说，一幅图像）相联系，且很少被访问，则可以定义一个将此域排除在外的域组，该域组与一个查找方法相关联，这样查找时，BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。
? 并发策略：在WebLogic Server 7.0中，容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施，它的主要目的是确保实体bean所表示的数据的一致性，该一致性由bean的部署器所强制要求。无论如何，某些控制机制使得容器处理请求的速度比其它的要快一些，但这种快速是以牺牲数据的一致性为代价的。
最严格的并发策略是独占式，利用特殊主键对bean的访问是经过系列化的，因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制，但性能受到限制。在交易之间允许互为缓存的时候，这种方法很有用，但在集群环境中不能使用，此时，装载操作被优化掉，因此可能导致丧失并行性。
数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定，允许多个交易对相同的实体bean并发操作，因此能够提高性能。当然，这样对隔离的级别也许要求较高，以便确保数据的一致性。
积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下，本策略比数据库式的策略要快一些，虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候，本策略要求调用者要重新发起调用。 本特征也只对EJB 2.0 适用。
只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时，也会通过read-mostly格式通知bean,从而引起重新装载。
? 紧密关联缓存： 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联，两个在同一个交易中被访问，且由同样的数据库调用装载，我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征，同样只适用于EJB2.0。
除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外，另有一些在容器之外，针对会话bean和实体bean的参数能够帮助提升性能。
缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而，这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高，虽然这不是主要的问题。缓冲池适用于无状态会话bean（SLSB），消息驱动bean（MDB）以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小，这些bean的许多实例就会被创建并被放到缓冲池中，setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数（事实上，要求比此数要小）。如果方法setSessionContext()要做任何开销昂贵的操作的话，此时JNDI查询已经完成，使用缓冲池中的实例方法调用将会加快速度。对实体bean来说，在完成setEntityContext()方法调用之后，缓冲池与bean的匿名实例相连（没有主键）。这些实例可以被查询操作所使用，查询方法从缓冲池中取出一个实例，为其指定一个主键，然后从数据库中装载相应的bean。
高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB，缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵，绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些，这是由于仅当缓存被占用了85%以后，容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需，则容器不会通过缓存花费时间将bean待命。
EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作：传值调用和传送地址调用。如果bean处在同一个应用之中，则缺省情况下，用的是传送地址的方法，这比传值要快一些。传送地址的方法一般不应被禁止，除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活（activation）。虽然这种做法在某种程度上影响了性能，但由于对内存要求较低，因此极大地改进了扩展性。如果扩展性不值得关注，可以将参数noObjectAction传送给ejbc从而关闭激活（activation）。
#20
JDBC
对数据库的访问来说，调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小――连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现，则连接数应为执行队列中的线程数，比读取socket的线程（缺省执行队列中用来读取进入请求的线程）数要少。为了避免在运行期间对连接进行创建和删除，可在初始时即将连接池设置为其最大容量。如果可能的话，应确保参数TestConnectionsOnReserve被设置为假（false，这是缺省设置）。如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接。
另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存，大小由JDBC连接池配置时指定。缓存是静态的，时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话，则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能，但也不能盲目使用它。如果数据库的格式有了变化，那么在不重新启动服务器的情况下，无法使缓存中的语句失效或者是用新的进行替换。当然，缓存中的语句会使数据库中的光标得以保留。
对于WebLogic Server 7.0来说，由于jDriver性能的改进已使其速度远远快于Oracle的廋驱动程序，尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明（http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance）。
JMS
JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此，JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”，反过来也不会抢夺其它应用的资源。对JMS来说，大多数的调试参数都是在服务的质量上进行折衷处理。如，利用文件式持续性目的地（file-persistent destnation）禁止同步写操作（通过设置特性： －Dweblogic.JMSFileStore.SynchronousWritesEnabled =false）以后会引起性能急剧提高，但同时也会冒着丢失消息或者重复接收消息的风险。类似地，利用多点传送发送消息会提升性能，同时也会有消息半途丢失的危险。
消息确认间隔不应设置得过短――发送确认的比率越大，处理消息的速度可能会越慢。同时，如果设置得过大，则意味着系统发生故障时，消息会丢失或者被重复发送。
一般说来，应在单个服务器上对多个JMS目的地进行配置，而不是将它们分散在多个JMS服务器，除非不再需要扩展。
关闭消息页面调度（paging）可能会提高性能，但会影响可扩展性。如果打开消息页面调度（paging），则需要额外的I/O操作以便将消息串行化到硬盘，在必要的时候再读进来，但同时也降低了对内存的要求。
一般来说，异步过程比同步过程更好操作，更易于调节。
Web容器
Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据，然后使用servlet和JSP生成动态内容，其中应用层一般由EJB组成。在这种结构中，servlet 和JSP保留对EJB的引用，以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上，则利用JNDI进行查询的费用是很昂贵的。
JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容，对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化，则可以通过将ServletReloadCheckSecs 设置为－1，从而关闭自动装载（auto-reloading）功能。使用这种方法以后，服务器将不再轮询Web层是否有变化，如果JSP和servlet的数量很多，则效果是非常明显的。
这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的，可以考虑使用有状态会话bean来替代。
JVM调试
如今的大多数JVM具有自主调节功能，因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间，按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收（GC）处理。在这种设置环境中，如果堆太大的话，垃圾回收的间隔应设为一分钟或更长。最后，需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考：
http://edocs.bea.com/wls/docs70/perform/JVMTuning.html1104200。
服务器调试
除了由各个子系统提供的调试参数以外，还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效，仅当下列情况成立时再考虑使用这种方法：预定的吞吐量没有达到；等待队列（未开始处理的请求）过长；CPU仍有剩余。当然，这样做并不一定能改善性能。CPU使用率低可能是由于对服务器的其它资源竞争所致，如，没有足够的JDBC连接。当改变线程数时应考虑到这些类似的因素。
在WebLogic Server 7.0中，提供了配置多个执行队列的功能，并且能够在部署中定义处理特殊的EJB或JSP/servlet请求的执行队列。要做到这些，只要在运行weblogic.ejbc时将标志 －dispatchPolicy <队列名称> 传送给bean 即可。对于JSP/servlet，可将设置Web应用的weblogic部署描述符中初始化参数（init-param） wl-dispatch-policy的值设为执行队列的名字即可。有时应用中的某些bean/JSP对操作的响应时间比其它的要长，此时，可以对这些bean/JSP设置单独的执行队列。至于队列的大小，要达到最好的性能，还取决于经验。
另一个比较大的问题是决定在何种情况下应该使用WebLogic性能包（http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html - 1112119）。如果socket数不太多（每个服务器上都有一个socket用于客户端JVM的远程方法调用连接），而且总是忙于读取从客户端发送过来的请求数据，那么此时使用性能包恐怕不会有明显的改进。也有可能不用性能包会导致相似或更好的结果，这取决于JVM在处理网络I/O时的具体实现。
Socket读取线程取自缺省执行队列。在Windows 环境下，每个CPU有两个socket读取线程，在solaris环境下，共有三个socket用于本地输入输出(native I/O)。对于Java 输入输出（I/O），读取线程数由配置文件config.xml中的参数PercentSocketReaderThreads 进行设置。它的缺省值是33%, 上限是50%，这是显而易见的，因为如果没有线程用于处理请求，则同样不会有更多的读取线程啦。对于Java I/O，应使读取线程数尽量接近客户端连接数，因为在等待请求时，Java I/O会阻塞。这也是为什么当客户端的连接数增加时，线程数不能一直同等增加的原因。
结论
我们上面只讨论了调试服务器的部分方法。需要记住的是，一个设计蹩脚，编写欠佳的应用，通常都不会有好的性能表现，无论对服务器及其参数如何调试。贯穿应用开发周期的各个阶段――从设计到部署，性能始终应该是考虑的关键因素。经常发生的情况是性能被放在了功能之后，等到发现了问题再去修改，已经很困难了。有关WebLogic Server 性能调试的其它信息可以参考：http://e-docs.bea.com/wls/docs70/perform/index.html。
对数据库的访问来说，调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小――连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现，则连接数应为执行队列中的线程数，比读取socket的线程（缺省执行队列中用来读取进入请求的线程）数要少。为了避免在运行期间对连接进行创建和删除，可在初始时即将连接池设置为其最大容量。如果可能的话，应确保参数TestConnectionsOnReserve被设置为假（false，这是缺省设置）。如果此参数设置为真（true），则在连接被分配给调用者之前，都要经过测试，这会额外要求与数据库的反复连接。
另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存，大小由JDBC连接池配置时指定。缓存是静态的，时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话，则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能，但也不能盲目使用它。如果数据库的格式有了变化，那么在不重新启动服务器的情况下，无法使缓存中的语句失效或者是用新的进行替换。当然，缓存中的语句会使数据库中的光标得以保留。
对于WebLogic Server 7.0来说，由于jDriver性能的改进已使其速度远远快于Oracle的廋驱动程序，尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明（http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance）。
JMS
JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此，JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”，反过来也不会抢夺其它应用的资源。对JMS来说，大多数的调试参数都是在服务的质量上进行折衷处理。如，利用文件式持续性目的地（file-persistent destnation）禁止同步写操作（通过设置特性： －Dweblogic.JMSFileStore.SynchronousWritesEnabled =false）以后会引起性能急剧提高，但同时也会冒着丢失消息或者重复接收消息的风险。类似地，利用多点传送发送消息会提升性能，同时也会有消息半途丢失的危险。
消息确认间隔不应设置得过短――发送确认的比率越大，处理消息的速度可能会越慢。同时，如果设置得过大，则意味着系统发生故障时，消息会丢失或者被重复发送。
一般说来，应在单个服务器上对多个JMS目的地进行配置，而不是将它们分散在多个JMS服务器，除非不再需要扩展。
关闭消息页面调度（paging）可能会提高性能，但会影响可扩展性。如果打开消息页面调度（paging），则需要额外的I/O操作以便将消息串行化到硬盘，在必要的时候再读进来，但同时也降低了对内存的要求。
一般来说，异步过程比同步过程更好操作，更易于调节。
Web容器
Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据，然后使用servlet和JSP生成动态内容，其中应用层一般由EJB组成。在这种结构中，servlet 和JSP保留对EJB的引用，以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上，则利用JNDI进行查询的费用是很昂贵的。
JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容，对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化，则可以通过将ServletReloadCheckSecs 设置为－1，从而关闭自动装载（auto-reloading）功能。使用这种方法以后，服务器将不再轮询Web层是否有变化，如果JSP和servlet的数量很多，则效果是非常明显的。
这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的，可以考虑使用有状态会话bean来替代。
JVM调试
如今的大多数JVM具有自主调节功能，因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间，按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收（GC）处理。在这种设置环境中，如果堆太大的话，垃圾回收的间隔应设为一分钟或更长。最后，需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考：
http://edocs.bea.com/wls/docs70/perform/JVMTuning.html1104200。
服务器调试
除了由各个子系统提供的调试参数以外，还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效，仅当下列情况成立时再考虑使用这种方法：预定的吞吐量没有达到；等待队列（未开始处理的请求）过长；CPU仍有剩余。当然，这样做并不一定能改善性能。CPU使用率低可能是由于对服务器的其它资源竞争所致，如，没有足够的JDBC连接。当改变线程数时应考虑到这些类似的因素。
在WebLogic Server 7.0中，提供了配置多个执行队列的功能，并且能够在部署中定义处理特殊的EJB或JSP/servlet请求的执行队列。要做到这些，只要在运行weblogic.ejbc时将标志 －dispatchPolicy <队列名称> 传送给bean 即可。对于JSP/servlet，可将设置Web应用的weblogic部署描述符中初始化参数（init-param） wl-dispatch-policy的值设为执行队列的名字即可。有时应用中的某些bean/JSP对操作的响应时间比其它的要长，此时，可以对这些bean/JSP设置单独的执行队列。至于队列的大小，要达到最好的性能，还取决于经验。
另一个比较大的问题是决定在何种情况下应该使用WebLogic性能包（http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html - 1112119）。如果socket数不太多（每个服务器上都有一个socket用于客户端JVM的远程方法调用连接），而且总是忙于读取从客户端发送过来的请求数据，那么此时使用性能包恐怕不会有明显的改进。也有可能不用性能包会导致相似或更好的结果，这取决于JVM在处理网络I/O时的具体实现。
Socket读取线程取自缺省执行队列。在Windows 环境下，每个CPU有两个socket读取线程，在solaris环境下，共有三个socket用于本地输入输出(native I/O)。对于Java 输入输出（I/O），读取线程数由配置文件config.xml中的参数PercentSocketReaderThreads 进行设置。它的缺省值是33%, 上限是50%，这是显而易见的，因为如果没有线程用于处理请求，则同样不会有更多的读取线程啦。对于Java I/O，应使读取线程数尽量接近客户端连接数，因为在等待请求时，Java I/O会阻塞。这也是为什么当客户端的连接数增加时，线程数不能一直同等增加的原因。
结论
我们上面只讨论了调试服务器的部分方法。需要记住的是，一个设计蹩脚，编写欠佳的应用，通常都不会有好的性能表现，无论对服务器及其参数如何调试。贯穿应用开发周期的各个阶段――从设计到部署，性能始终应该是考虑的关键因素。经常发生的情况是性能被放在了功能之后，等到发现了问题再去修改，已经很困难了。有关WebLogic Server 性能调试的其它信息可以参考：http://e-docs.bea.com/wls/docs70/perform/index.html。