1.1. WAS在HP UX上的安装
HP UX为安腾Itanum(IA)，操作系统11.31，位版。
将WAS的安装文件tar.gz上传到服务器，假设文件名为WAS6.tar.gz 1、 gzip –d WAS6.tar.gz 加压缩得到WAS6.tar
2、 安装时需要hpux_ia（含WAS）以及hpux_ia6_suppl（含IHS和Plugin）两张光盘 3、 tar xvf WAS6.tar 解tar
4、 export DISPLAY=本地IP地址:0
5、 ./launchpad.sh 运行后会在本地出现下面窗口
6、 先安装UpdateInstall，然后将UpdateInstall安装目录中的java作为JAVA_HOME，
并将路径放置到PATH中，具体做饭见1.2中的第4步，否则在安装的时候会说JVM的版本不对
7、 安装WAS，不选择安全，其他默认； 8、 安装IHS，不选择安全，其他默认； 9、 安装WebServer Plugin
10、 然后打29的补丁，在打补丁的时候，安装UpdateInstall时会出错误，提示有一个
目录（hotspot）有问题，该目录在6.0中是一个目录，在7.0中是一个文件，将之删除就可以。
11、 将补丁ftp到UpdateInstaller的maintenance目录中，安装时可以自动找到，补丁的
安装方法见下面。
1.2. WAS补丁的安装
1、 在本地启动Xmanager –Passive监控，等待接收图形信息；
2、 将下载的WAS补丁上传到服务器的WAS安装路径的maintenance目录中（放在这
个目录中可以直接找到，如果放在其他目录中则需要在安装时指定）；updater程序需要解压后上传；
3、 在Unix服务器上执行下面命令，将图形信息传递到指定IP地址上
Export DISPLAY=本地IP地址:0
4、 运行updater目录中的install或者update.sh（因操作系统不同而不同），如果该文件
不能被执行，那么使用chmod命令来修改。当服务器中默认使用的JDK的版本与WAS使用的JDK的版本不同时，会无法运行，可以使用下面方法指定使用的JDK： export JAVA_HOME=WAS使用的JDK的绝对路径（设置Java_home，WAS的JDK） export PATH=$JAVA_HOME/bin:$PATH（将WAS使用的JDK加入路径中） echo $PATH（检查路径设置是否正确）
java –jar setup.jar（执行Updater，在Updater目录中执行）
5、 Updater运行后，图形界面会出现在本地机器上，需要先升级服务器上的Updater程
序，然后升级WebServer、Plugin、IHS等，
升级前需要关闭所有WAS服务器，如果没有关闭，那么在升级过程中会提示关闭。
1.3. WAS61中建立profile
1、创建集群profile
分别创建管理节点（mgr profile）和受管节点（managed profile），命令分别如下（需在{$WAS_HOME}/bin目录下执行，如/opt/IBM/WebSphere/AppServer/bin/）：
删除管理节点和受管节点：
./manageprofiles.sh -delete -profileName mgr01 创建管理节点： ./manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/dmgr -profileName mgr01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/mgr01 -isDefault –omitAction
创建受管节点： ./manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/managed -profileName node1 -profilePath /opt/IBM/WebSphere/AppServer/profiles/node1 -isDefault –omitAction
创建非受管节点： ./manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/default -profileName node1 -profilePath /opt/IBM/WebSphere/AppServer/profiles/node1
-templatePath：模板路径及模板（default非集群节点，mgr为集群节点，managed为受管节点，当此节点需加入集群时用）
-profileName：节点名 -profilePath：节点路径
2、将受管节点加入到管理节点的管理之下
（1）启动管理节点：/opt/IBM/WebSphere/AppServer/profiles/mgr01/bin/startManager.sh （2）加入受管节点： 进入/opt/IBM/WebSphere/AppServer/bin/目录，执行： ./addNode.sh dmgr_host dmgr_port -profileName 说明： dmgr_host：管理节点所在机器IP； dmgr_port：Deployment manager SOAP connector port，如：8879 dmgr_port可以通过/opt/IBM/WebSphere/AppServer/profiles/mgr01/bin/dumpNameSpace.sh来查看。 1.4. WAS61中建立集群 管理节点和受管节点建立完毕，启动管理节点和受管节点后，可以通过WAS的控制台建立集群和集群中的Server。 启动管理节点：/opt/IBM/WebSphere/AppServer/profiles/mgr01/bin/startManager.sh 启动受管节点：/opt/IBM/WebSphere/AppServer/profiles/node01/bin/startNode.sh 启动完毕后，可以进入WAS控制台， 进入服务器—>集群，点击新建按钮，就可以新建一个集群，在新建集群的同时，可以新建集群中的Server， 2. WAS的配置 2.1. WAS中MQ的配置 在WAS集群中配置对应的MQ集群时，要将MQ中的不同的队列管理器和队列对应到WAS的不同实例（Server）中。在不同的实例（Server）中为队列管理器和队列指定相同的JNDI名称，并在Server中建立相同名称的侦听（服务器—>应用程序服务器Server—消息传递—消息侦听器服务侦听器端口，新建一个），这样在MDB中就可以使用同一个侦听、队列管理器、队列JNDI名侦听集群中的全列管理器和队列了。 上图中每个Server中配置的侦听器名称，连接工厂JNDI名称，目标（队列）JNDI名称都应该是一致的，这样才可以保证访问MQ集群中的任意队列管理器。点击名称“LSN_AP”后可以设置侦听器的数量，同时还要对侦听服务器的连接池进行设置： 消息侦听服务的线程池的最大大小，一定要大于侦听器的数量。 同时设置线程池中，ORB线程的大小，最好要大于侦听器的数量，其中WebContainer的数量，为可以接收的Web访问的最大数量。 在队列管理器（资源JMS队列连接工厂，选择相应作用域，新建WebSphere MQ messaging provider类型的队列连接工厂）的配置中，当WAS和MQ安装在同一台机器上，那么连接方式采用Binding；如果没有安装在一台机器上，那么选择Client方式。 下图为队列管理器名称的设置： 对于WAS集群中所有的队列连接工厂的JNDI名称都应该一致。连接池的最大连接数量为侦听数*2（按照下面说明进行），会话池中的最大连接数为侦听数。 下图为队列管理器中端口号、通道等属性的设置： 队列管理器不必设置，只需要设置MQ队列管理器所在主机的IP地址、端口号、通道、传输类型（尽量设置为Client），CCSID（819为中文）、不选中“启用消息保留”。对于非集群部署的MQ，队列管理器可以设置成对应的队列管理器的名称。 在队列（资源JMS队列，选择相应作用域，新建WebSphere MQ messaging provider类型的队列）配置中，对于消息发出队列的消息发出类型应该设置为：非持久，且在MQ配置中的队列类型也设置为非持久。对于集群中的其他队列管理中队列的访问，除队列名称为指定队列名称外，其对应的队列管理器、端口号和连接通道都可以设置为本地队列管理器，MQ集群会负责把消息通过本地的队列管理器发送到远程队列管理器的指定队列中。 队列名称设置如下图： 对于WAS集群中所有的队列的JNDI名称都应该一致。点击“MQ配置”后，会出现队列的详细信息，表明队列设置无误，将其中的持久性选择为“不持久”。 队列的其他设置，持久性设置为“非持久”这样所有通过该队列发送的报文都是非持久的，而不管应用程序中的设置。基本队列名为指定队列名称，队列管理器名称可以为空，CCSID为819中文。对于非集群部署的MQ，基本队列管理器可以设置成对应的队列管理器的名称。 队列的详细属性设置：目标客户机选择为MQ，设置本地的队列管理器主机IP、端口号和连接通道即可。在使用集群中远程队列管理器上的队列时，队列名为指定队列的名称，队列管理器IP、端口号、连接通道都填本地的队列管理器的属性即可。 目标客户机选项为JMS、MQ，设置成MQ时会自动把JMS的报文头过滤掉，当设置成JMS时，收到的报文会带有JMS的报文头。当与C语言程序互相交换报文时，需要选择MQ方式；如果与Java语言的程序交互报文时，且JMS头中带有有用信息时，需要采用JMS方式。 MQ集群队列和队列管理器的配置中，不必设置队列管理器名称，只需要设置队列管理器的IP地址、端口号和连接通道即可。 队列管理器的连接工厂的最大连接数=侦听中连接数 * 2。在实际设置中，侦听数指的是从队列中读取消息的MDB的数量，该数量是从队列中可以并行读取的消息的个数；再加上往该队列中并行写入消息的个数即可，所以最大连接数不一定是侦听中连接数的2倍。 在应用中将队列和队列管理器的认证类型设置为容器（Container）。 在WAS中设置队列管理器时，如果将连接方式设置为Binding方式，当MQ和WAS不安装在同一台机器上时，会提示找不到类库，也就是在Java虚拟机中无法加载MQ的动态 库（so），可以将MQ安装路径下的/usr/mqm/java/lib下的so复制到安装WAS的机器的任意目录中（注意，如果WAS安装在位的操作系统中，那么要使用lib下的so），然后在JDK的编译参数中增加java –Djava.library.path=(so的存放路径)或者在路径中增加export LIBPATH=${LIBPATH}|(so的存放路径)。 在MQ中可以直接配置连接工厂和队列的JNDI文件，配置方式与内容与在WAS相似。 2.2. WAS中数据源的配置 设置JDBC提供程序：资源JDBCJDBC提供程序 设置数据源：资源—>JDBC数据源。 当有两阶段事务（MQ事务和数据库事务，连接两个不同的数据库）的时候要使用XA数据源。 在数据源的定制属性中使用user和password分别指定数据库的用户名和口令，以便在连接数据库的时候使用，因为有时配置认证机制时不管用。 可以将数据源的连接池的最小值设置为0，超时时间设短，这样连接使用后，一旦超时就会自动被容器回收。 在Aix中建立数据源后，在定制属性中会多一个connectionSharing的属性，在连接测试的时会出现警告，可以将该属性删除。 在应用中将数据源的认证类型设置为应用（Application）。 2.3. WAS侦听端口号的配置 在WAS控制台的环境—>虚拟主机中设置可以侦听的端口号，只有在该处进行了设置，那么在IE中才可以通过指定端口访问。要把WAS各实例所侦听的端口号都在此进行设置。 2.4. WebServer的配置 在新安装一个应用的时候，有时并不能通过IHS访问，因为新安装的应用不会自动出现在WebServer的plugin中，此时可以在WAS控制台的服务—WebServer中删除Web Plugin，然后再重新生成就可以了。 在WAS控制台（服务器Web服务器）上生成WAS WebServer Plugin时会重新生成 plugin.xml，在生成完毕后可以检查该配置文件中是否已包含新增应用的Web路径。 同时检查WebServer的httpd.conf文件中，是否使用了正确目录下的plugin.xml。 WebServer的启动比较慢，要多等一会，就可以通过80端口访问指定应用了。 新建Web服务器的时候，有时会无法启动，先生成插件，然后再传播插件后即可启动。 配置文件为WebServer的配置文件httpd.conf的内容，插件属性为plugin-cfg.xml的内容。 2.5. Server中Jvm参数的设置 服务器应用程序服务器serverJava和进程管理进程定义—>Java虚拟机中设置JVM的参数 调试参数 -Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777 通用Jvm参数 -Xoptgc -XX:SurvivorRatio=16 -Xmn768m -Xnoclassgc -XX:+ForceMmapReserved -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=360000 设置Java虚拟机的内存大小，初始大小和最大小，可以设置为一样的，在Windows中最大不要超过1G，在Unix中可以设置4G以上。 详细见：java_debug.txt和Java_params.jpg。 3. WAS的日常维护 3.1. WAS的停止与启动 1、 WAS集群的停止 ①进入WAS的控制台（http://ip:9060/admin或者http://ip:9060/ibm/console）后选择要停止的集群，并停止；也可以进入WAS实例（server）所在的节点的bin目录中，使用（./stopServer.sh 实例名）来分别停止WAS实例。建议在控制台中停止整个集群，因为这样好像是并行的，而通过stopServer命令则必须是串行的； ②进入WAS实例所在节点的bin目录中，使用./stopNode.sh停止节点； ③进入WAS的域管理节点的bin目录中，使用./stopManager.sh停止域管理服务。 2、 WAS的启动 ①进入WAS的域管理节点的bin目录中，使用./startManager.sh启动域管理服务 ②进入WAS实例所在节点的bin目录中，使用./startNode.sh停止节点； ③进入WAS的控制台（http://ip:9060/admin或者http://ip:9060/ibm/console）后选择要启动的集群，并启动；也可以进入WAS实例（server）所在的节点的bin目录中，使用（./startServer.sh 实例名）来分别启动WAS实例。建议在控制台中启动整个集群，因为这样好像是并行的，而通过startServer命令则好像是串行的。 3、 HTTP Server的启动和停止 先在Was控制台上停止Web Server的Plugin 进入HTTP Server安装目录的bin目录中， 启动命令：./adminctl start 停止命令：./adminctl stop 启动后再在WAS控制台上启动WebServer的plugin 插件配置文件plugin.xml存放在目录：/opt/IBM/HTTPServer/Plugins/config /webserver1/plug-cfg.xml中。 Httpd配置文件存放在：/opt/IBM/HTTPServer/conf/httpd.conf，该配置文件可以在WAS控制台上修改。 4、 节点同步 系统管理—>节点，可以同步节点 系统管理—>Node Agent中可以重新启动节点 3.2. WAS的垃圾回收日志 存放在每个Server的日志目录的native_stdout.log文件中。 使用ps –ef|grep java命令，根据进程属性可以判断该进程属于WAS的哪个Server，使用kill -3 进程号命令可以将JVM的例外写入native_stdout.log中，进行检查，该方法还没有验证？？ 3.3. WAS的监控 监视和调整性能查看器当前活动 在右侧窗口中选择要查看的性能模块，选择完毕后点击“查看模块”按钮，然后点击“启动记录”按钮，就可以开始选择模块的处理性能监控。 4. WAS中的应用程序 4.1. WAS中应用的配置 应用程序企业应用程序，选择要配置的应用程序 注意工程中的类加载顺序 选择“启用Url重写”选项，注意会话超时设置。其中URL重写选项最好在Server和应用中都选中，如果没有选中该选项，那么有可能会无法创建Session。 4.2. 普通的Web工程 普通的Web工程，可以使用Eclipse、JBuilder等工具生成，不含有EJB，只能生成War包，而不是Ear包。在这些工程中如需访问WAS中的JNDI资源，需要把JNDI资源在Web.xml中做一个映射后才可以访问，映射的格式如下： //下面是数据源的映射，认证方式为应用（application） 4.3. EJB工程 在EJB工程中，每个工程都要配置自己使用的JNDI资源，在EJB部署描述符和Web部署描述符中都要指定其使用的JNDI资源。 在EJB工程中，可以使用Java环境，也就是在使用JNDI资源时，JNDI名称中不需要指定java:com/env，直接写JNDI名称即可。 在AST中进入EJB工程，进入META-INF目录，双击ejb-jar.xml，打开“EJB部署描述符”如下图，下图是数据源在EJB工程中的配置。 在设置数据源时，需要在每个MDB中配置需要使用的JNDI资源（队列工厂、队列、数据源等）。如上图所示，在MDB中使用的数据源的名称为jdbc/ACSTADB，选择数据源的类型（javax.sql.DataSource），数据源的认证类型一般为Application，使用应用程序的认证，最后在WebSphere绑定中指定数据源在WebSphere中的JNDI名称。数据源的配置结束。 在设置队列连接工程和队列的数据源时，数据源的类型应选择为javax.jms.QueueConnectionFactory或者javax.jms.Queue，认证类型为Container，使用容器的认证即可。其他的配置同数据源的配置。 在MDB中设置完资源后，还需要对每个MDB对应的WAS中的侦听器进行设置，WAS中侦听器的配置见2.1WAS中MQ的配置中的描述。侦听器的配置在“Bean”标签中完成。如下图所示： 需要配置每个MDB对应的WAS中侦听器的名称。 4.4. WAS应用中通用类的路径 1、获得WAS使用的WSDLjar包的路径 javax.wsdl.extensions.ExtensionRegistry.class.getProtectionDomain().getCodeSource().getLocation().toString() 2、获得WAS使用的db2jar包的路径 com.ibm.db2.jcc.DB2ConnectionPoolDataSource.class.getProtectionDomain().getCodeSource().getLocation().toString() 4.5. Eclipse中工程的属性 Eclipse中的Java工程与Web工程可以通过属性来设置。如果属性设置不对，那么有可能会出现在Web工程中无法引用的情况。 在工程上点击右键，选择“属性”或者直接Alt+Enter，打开工程的属性设置窗口： 选择Project Facets选项，在右侧窗口中会显示所有的可选Facets，对于Web工程需要选择Dynamic Web Module（版本为2.4）和Java选项；对于普通的Java工程需要选择Java选项；如果该Java工程会被Web工程引用，那么还需要选中Utility Module选项，该选项允许本工程可以被Web工程引用，如果不设置本选项，那么在Web工程的Java EE Module Dependency中会看不到所要引用的工程。 在设置好工程的Facets属性后，就可以在Web工程的Java EE Module Dependency中引用该工程了，这样就可以把Web工程连同所引用工程一起部署到Web Server上。 如果需要把一个普通的Java工程设置为Web工程，只需要通过修改该工程的Project Facets属性，选择Web工程所需的属性即可。 4.6. WAS应用中的日志 4.6.1. 日志的级别？？ 软件中总免不了要使用诸如 Log4net、Log4j、Tracer等工具来写日志，不管用什么，这些工具大多是大同小异的，一般都提供了这样5个日志级别： Debug、Info、Warn、Error、Fatal 一个等级比一个高，但是在具体开发中，关于应该如何选择适应的等级，却没有找到好的文章进行说明。记录一下自己的一些看法，以便日后使用吧。 一、=== Debug === 这个级别最低，一般的来说，在系统实际运行过程中，一般都是不输出的。 因此这个级别的信息，可以随意的使用，任何觉得有利于在调试时更详细的了解系统运行状态的东东，比如变量的值等等，都输出来看看也无妨。 当然，在每一个 Debug 调用之前，一定要加上 If 判断。 二、=== Info === 这个应该用来反馈系统的当前状态给最终用户的，所以，在这里输出的信息，应该对最终用户具有实际意义，也就是最终用户要能够看得明白是什么意思才行。 从某种角度上说，Info 输出的信息可以看作是软件产品的一部分（就像那些交互界面上的文字一样），所以需要谨慎对待，不可随便。 三、=== Warn、Error、Fatal === 警告、错误、严重错误，这三者应该都在系统运行时检测到了一个不正常的状态，他们之间的区别，要区分还真不是那么简单的事情。我大致是这样区分的： 1、所谓警告，应该是这个时候进行一些修复性的工作，应该还可以把系统恢复到正常状态中来，系统应该可以继续运行下去。 2、所谓错误，就是说可以进行一些修复性的工作，但无法确定系统会正常的工作下去，系统在以后的某个阶段，很可能会因为当前的这个问题，导致一个无法修复的错误（例如宕机），但也可能一直工作到停止也不出现严重问题。 3、所谓Fatal，那就是相当严重的了，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话，可以肯定必然会越来越乱。这时候采取的最好的措施不是试图将系统状态恢复到正常，而是尽可能地保留系统有效数据并停止运行。 也就是说，选择 Warn、Error、Fatal 中的具体哪一个，是根据当前的这个问题对以后可能产生的影响而定的，如果对以后基本没什么影响，则警告之，如果肯定是以后要出严重问题的了，则Fatal 之，拿不准会怎么样，则 Error 之。 四、=== 一些疑惑 === 不过在实际使用中，基于上面的这种考虑，也还是有一些具体问题。最常见的就是要在最终产品中将输出日志打开到那种级别才算好呢？ 例如在应用中有一个输出窗口，一些系统状态信息将被输出到这个输出窗口中。因为 Info 的级别是如此之低，所以为了让用户能够看到有效的输出信息，必须将日志级别开放到 Info 级别。但是 Warn 的级别比 Info 要高，所以用户不得不被迫看到一些 Warn 的信息。而我们其实已经假定，Warn 信息其实并不影响系统的正常运行，这一般只代表系统中存在一些还没有被发现或者修改的小 Bug。这些 Warn 信息会让最终用户困惑甚至恐慌，系统发出警告了，该怎么办？ 个人观点，Info 的级别应该比 Warn 更高才对，Warn 信息和 Debug 一样，应该在产品测试和调试时使用，而 Info、Erro 以及 Fatal 则在产品发布后需要继续使用。 目前我所采用的解决方法是，对于 Warn、Error、Fatal 都添加一个相应的系统断言，这样，可以保证当发生这种问题时，在调试阶段，可以立即得到提示。在软件发布以后，这些信息也能被记录到日志文件中去。 {{{ log.Warn(\"message\"); System.Diagnostics.Debug.Fail(\"警告\}}} Debug.Fail 将导致编译为 Debug 输出时，会弹出一个消息警告窗口，这可保证在测试、调试阶段不漏过任何一个潜在的错误。而在发布时，Release 编译的输出不会包括 Debug 语句，这就不会打扰最终用户，而错误信息仍然能通过 log 记录到日志中。 另外，还有两个可用的特别的日志记录级别: ALL、OFF：ALL Level是最低等级的，用于打开所有日志记录；OFF Level是最高等级的，用于关闭所有日志记录。 日志记录器（Logger）的行为是分等级的。如下表所示： 分 为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。Log4j建议只使用四个级别，优先级从高到低分别是 ERROR、WARN、INFO、DEBUG。 Eclipse中的Java工程与Web工程可以通过属性来设置。如果属性设置不对，那么有可能会出现在Web工程中无法引用的情况。 5. WAS配置中的经验 5.1. Web Container的数量和数据源的数量 WAS中Web Container的数量和数据库连接池的数量都是针对一个Server（实例）而言的，有几个Server，总数量就会乘以几。 虽然Web Container的数量越大，数据库连接池的数量越大，能够接收的Web访问和处理的数据库访问就越多，但是这两个数量越大，应用的吞吐量确不一定会增大，因为大量的并发进入，会导致单个进程的处理时间变短。 一般情况下，Web Container的数量，应该比数据库连接池的数量要小，这样可以保证每个进入的Web访问都可以获得数据库资源。同时，所有Server中Web Container数量的合计应该比并发用户的数量大一些就可以，不必大太多，大太多反而会影响吞吐量。 例如：在普元工作流测试的时候，在测集中部署的场景时，有4个Server，500并发用户，最初Web Container的数量设置为600，数据库连接池为400，此时的吞吐量还不到900/s；当把Web Container的数量设置为200，数据库连接池设置为300时，吞吐量反而达到1050/s；当把Web Container的数量设置为150，数据库连接池设置为200时，吞吐量仍然达到1070/s。可见只要Web Container的合计大于并发用户，那么就没有必要大幅增加其数量。 5.2. WAS性能调优IBM篇 部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用，一个请求到来时，往往需要经过多次转发：网络-->Web服务器-->Web容器-->EJB容器-->数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。 对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。在实践中我们发现，为了达到这个目的，最有效的配置方式就是使得队列成为一个“漏斗”。也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。按照这个原则，调优的基本步骤如下： 1、设置的是Web Server的最大并发用户： 这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。 2、设置Web Container的最大、最小并发用户： 在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer，根据观察的性能情况和应用情况输入合适的最小、最大进程数。 3、对象请求代理（ORB）的线程池大小： 在管理控制台中点击应用程序服务器 > server1 > ORB 服务 > 线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。 4、设置数据库的连接池属性： JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池，根据观察的性能情况和应用情况输入合适的最小、最大连接数。 这个最难把握，因为最大连接数、最小连接数、连结超时、获得时间等等都要依据数据 库及网张络的性能来调整。而且获得时间、不使用超时、时效超时是互相联系的一组参数，一般来说：获得时间要小于不使用超时及时效超时，且三个不能为零，是最好的! 5、JVM堆参数设置的性能调优： 应用程序服务器 > server1 > 进程定义 > Java 虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。 6、ORB参数调用方式的性能调优： 应用程序服务器 > server1 > ORB 服务>选中按引用传递。 关闭动态加载开关： 企业应用程序 > 应用名称 > 关闭启动类重新装入开关。 关闭会话序列化，应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。 这个调优的步骤只是涉及了利用WAS服务器参数的调整来优化应用程序的性能，实际上性能的好坏很大部分是取决于应用的设计。好的性能源自好的代码设计。一般说来，性能调优大概可以提高10％－40％效率，而糟糕的代码设计却会使得性能几倍的下降。 5.3. LoadRunner客户端的设置 在Loadrunner进行测试的时候，有时候由于并发用户比较大，且执行速度很快，最造成LoadRunner提示服务器的80端口正在被占用，此时需要在注册表中对客户端的TCP参数进行调整\\HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters，调整内容如下： 把这两个改大。
因篇幅问题不能全部显示，请点此查看更多更全内容