1.Was 架构
池架构模型 :

漏斗模型：
通常，WebSphere应用中的一个请求到达服务器，到真正开始处理，要经过一系列的连接池。广域网上可能有大量的并发用户同时访问Web服务器，Web服务器上同时活动（Active）的连接可能高达10000个。但Web服务器到应用服务器（Web容器）的连接池大小可能只有200。Web容器到EJB容器的连接池更小，可能是80。然后，经过数据源（Data source）到数据库的连接最大可能只有25个。从Web服务器的连接池到数据库的连接池尺寸逐渐变小，像一个漏斗（funnel），所以称为漏斗模型。
摘自《构建高性能WebSphere企业级应用》第二章

IBM 000-253中有这么一道题：
According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?
A Web Server=75, Web container=75, Datasource =25
B Web Server=75, Web container=50, Datasource =25
C Web Server=50, Web container=50, Datasource =50
D Web Server=25, Web container=50, Datasource =75
根据漏斗模型，那么很显然应该选B。

2.WAS基本使用
应用部署

配置文件
1、server.xml
服务器参数配置文件
2、resources.xml
连接池配置文件
3、portdef.props
端口配置文件

2.1 参数配置
JVM 有关websphere jvm参数

a. 假设您运行 WebSphere Application Server 所在的 JVM 正是针对 WebLogic 进行调整的那个 JVM，则以上扩展应该是针对 WebSphere Application Server 调整 JVM 的一个良好起点，但您可能会根据负载测试进行调整。要将这些 JVM 参数添加到 WebSphere Application Server，请执行以下操作：
1. 从管理控制台中选择 Servers => Application Servers -=> server_name => Process Definition => Java Virtual Machine。
2. 选中 Verbose Garbage Collection（要记得将其关闭）。
3. 将 Initial Heap Size 设置为 1024。
4. 将 Maximum Heap Size 设置为 1024。
5. 添加 -server，作为 Generic JVM 参数框中的第一个参数，然后在现有的其他参数后面添加以下参数：
-XX:ParallelGCThreads=8
-XX:PermSize=128m
-XX:MaxPermSize=128m
-Xloggc:wls-gc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps

b. 牢记以下事项：
o 详细垃圾回收是通过 -verbose:gc 选项启用的。在负载测试过程中收集垃圾回收统计数据是很有帮助的，但大大小小的每次回收都会被记录下来，所以请记住在运行最终的基准之前要禁用详细垃圾回收。
o 类垃圾回收在缺省情况下是启用的，它负责删除不再拥有任何活动实例的类。类垃圾回收在其他 WebLogic 迁移中带来了性能和可伸缩性的问题，所以请通过添加此 JVM 参数来禁用它：
-Xnoclassgc

JVM调整方法
方法1：修改配置的方式
通过修改server.xml进行JVM堆大小的设置：
servel.xml文件路径：
/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/22Node01Cell/nodes/Node01/servers/server1

server.xml中修改或增加配置:

 <jvmEntries xmi:id="JavaVirtualMachine_1173423453121" verboseModeClass="false" verboseModeGarbageCollection="false" verboseModeJNI="false" initialHeapSize="512" maximumHeapSize="2048" runHProf="false" debugMode="false" debugArgs="-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777" genericJvmArguments="-Djava.awt.headless=true" disableJIT="false"/>

例如：
初始化内存：initialHeapSize=”512”
最大可用内存：maximumHeapSize=”2048”

配置建议：
java虚拟机（JVM）堆大小设置会影响Java的垃圾回收。如果堆设置过大，会占用过多的内存，使内存资源减少，从而会频繁的进行I/O操作来使用虚拟内存；堆设置过小，会使得对象可分配空间变小，一方面会频繁的使用垃圾收集机制来释放内存空间（每次垃圾收集都会耗用系统资源），而且容易出现OutOfMemoryError。所以不能设的过小，也不能过大。一般将起始JVM堆大小设置为最大JVM堆的1/4。

方法2：通过Websphere控制台控制台修改
在控制台中单击服务器 -> 应用程序服务器，如下图：

单击需要配置的应用服务器，如下图：

在“服务器基础结构”下，单击java和进程管理 ->进程定义 ，如下图：

在“其他属性”下，单击java虚拟机，如下图：

3.WAS的JVM详细垃圾回收如何开启？
3.1启用 Java 虚拟机概要分析和详细垃圾回收配置步骤
配置步骤：

1. 在控制台导航树中单击服务器 > 应用程序服务器
2. 单击选择所需应用程序服务器。
3. 在”服务器基础结构”下，单击 Java 和进程管理-> 进程定义。
4. 在”其他属性”下，单击 Java 虚拟机。
5. 选中配置Tab的详细垃圾回收选项。
6. 在通用 JVM 参数字段中输入 -agentlib:pmiJvmtiProfiler。
   
   注: WebSphere6.1中，JVM概要分析接口改为Java Virtual Machine Tool Interface (JVMTI)。之前版本是JVMPI。如果需要JVMPI的时候，也可以此处输入-XrunpmiJvmpiProfiler。另外，启用JVMTI接口对性能影响较大，尽量避免在生产环境中使用。
   7．点击应用或者确定。
7. 单击保存按钮。
   9．重启WebSphere应用服务器。

3.2. TPV监视JVM的状况

我们可以借助TPV和PMI来实时监视JVM，分析性能曲线来判断是否有内存泄漏的状况发生。 WebSphere性能监控基础结构(PMI)和Java虚拟机概要分析工具接口（JVMTI）可以帮助我们收集系统的性能状况数据，使用Tivoli性能查看器(TPV)以图形的方式显示这些数据（性能计数器），可以进一步证实是否系统正在发生内存泄漏。

2．1 PMI与TPV

PMI 提供WebSphere运行时和应用程序资源行为的一组全面的数据,。例如，PMI 提供数据库连接池大小、servlet 响应时间、 Enterprise JavaBeans（EJB）方法响应时间、Java 虚拟机（JVM）垃圾回收时间以及 CPU 使用量等等。使用 PMI 数据，可以识别并修正应用程序服务器中的性能瓶颈, 还可使用 PMI 数据来监控应用程序服务器的运行状况。PMI 数据可以由 Tivoli Performance Viewer（TPV）、其他 Tivoli 工具、您自己的应用程序或第三方工具来监控和分析。TPV 是随 WebSphere Application Server 一起提供的 PMI 数据图形查看器。

Tivoli Performance Viewer（TPV）使得我们可以通过查看图表或表格，从而解读WebSphere的性能监控基础结构（PMI）数据。

2.2 PMI的配置方法

默认情况下，PMI已经开启，级别是默认(Default)。配置步骤：

1. 在控制台导航树中单击监视＆调整-> 性能监视基础结构(PMI)。

2. 选择所要配置的服务器名字。

3．单击配置选项卡，这里可以根据监控内容的需要，来选择PMI的任一种统计信息集（无，基本，扩展，全部，定制）。我们这里选择”定制”。

注：如果在配置选项卡中，则当重新启动服务器时应用设置。如果在运行时选项卡中，则立即应用设置。

4．点击定制 -> 在定制监视级别的树中，选择配置选项卡，然后点开JVM运行时，可以根据需要，启用或禁用相应的计数器。

点击定制，启用或禁用相应的计数器。

5．保存并重启WebSphere服务器

2.3 TPV的使用方法

实时查看 TPV 性能模块的步骤
（1） 在控制台导航树中，单击监控和调整 -> 性能查看器 -> 当前活动 -> 服务器名字）-> 性能模块。

（2） 选中要查看的每个性能模块，例如JVM运行时。

（3） 单击查看模块按钮。 在页面的右侧会显示所选性能数据的图形或切换成表格。 注：每个模块有与其关联的多个计数器。这些计数器会显示在数据图形或表格下面的表中。您可以通过选择或取消选择计数器旁的复选框，将计数器添加到图表或表中，或从中除去。
TPV需要SVGView插件。(但是官网信息:Adobe discontinued support for Adobe SVG Viewer on January 1, 2009.所以作罢)

Using TPV without Scalable Vector Graphics (SVG) as follow :

TPV显示的已使用内存的图形理想情况下应该是锯齿状，图形中每个坡（下降）对应着一次内存的垃圾回收(Garbage collection)，如下图已使用内存的曲线，显示的是没有发生内存泄漏的状况。

如果测试过程中出现如下情况，则有可能发生了内存泄漏：
－每次垃圾回收后的已使用内存的数值骤增。

－TPV对应的已使用内存图形更接近于阶梯（staircase），或者锯齿形状严重不规则。

－也可以查看分配的对象数与释放的对象数之差值，如果这个数值越来越大，则有内存泄漏（如果需要查看对象数，需要启用JVMTI接口并在PMI中启用相应的JVM计数器）。

上图，红色曲线代表已使用的内存，从整体趋势，我们可以看出已使用内存一直在增长。 TPV可以帮助发现内存泄漏，为了得到最优结果，我们可以重复试验，而且每次可以增加测试的时间，例如测试1000，3000或5000个页面请求。

3.1 Web容器线程池
“通常，对于每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。比如你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。但是一般考虑到能充分利用CPU和Memory，或者为不同的应用启用不同的application server，一台Pc Server上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，所以默认的10到50（Linux 系统上 25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。
在进行性能测试的时候，如果吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要立刻就调大线程池的设置——往往吞吐率会更一步下降。这时候要注意CPU占用率的情况、vmstat的r列值，特别是System状态占用率的情况，如果接近10%，甚至超过10%，那么可以肯定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。

设置方法：
方法1、控制台
服务器 > 应用程序服务器 > server_name > 线程池。

方法2、改文件server.xml:

参考：
线程池的介绍及简单实现
http://www.ibm.com/developerworks/cn/java/l-threadPool/
http://space.itpub.net/11605445/viewspace-600491
http://www-900.ibm.com/cn/support/faqhtmlfaq/1497069L01000.html

3.2 会话管理
应用程序>企业应用程序 > PlantsByWebSphere > 会话管理

也可修改server.xml文件进行配置:
maxInMemorySessionCount=”1000”
invalidationTimeout=”30”

3.3 数据库连接池
连接池的最小值，应该和性能测试时TPV观察到的jdbc平均大小一样，最大值根据实际需要设置，每次增长可以设置成大于1，增长一次到位。总之尽量避免连接池频繁的增长和收缩，减少wait的情况发生。

可以使用 Tivoli Performance Viewer 查找池中最优连接数。如果并发等待者的数目大于 0，但是 CPU 负载未接近 100%，那么考虑增加连接池大小。如果使用百分比值一直低于正常工作负载，那么考虑减少池中的连接数。

Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：
如果运行包含三个服务器的集群，这三个服务器都使用 myDataSource，并且 myDataSource的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）

这是需要考虑的，别数据库端的连接大小不够了。此外，inactive timeout和timeout的时间应该大于收集时间。
设置方法：
方法1：
在WebSphere 控制管理台配置数据库连接池，请按照以下步骤在WebSphere 控制管理台配置数据库连接池：
1. 登录到WebSphere Application Server管理控制台。
2. 点击资源 -> JDBC 提供程序。
3. 选择你的应用服务器。
4. 选择WebSphere Commerce的JDBC 提供程序。
5. 在“其他属性”中点击数据源。
6. 选择WebSphere Commerce的数据源。
7. 在“其他属性”中点击连接池属性。
8. 该页将显示数据源的连接池属性，你可以更改相应的值。

方法2：
修改resources.xml文件：

<factories xmi:type="resources.jdbc:DataSource" xmi:id="DataSource_1183122165968" name="PLANTSDB" jndiName="jdbc/PlantsByWebSphereDataSource" description="Data source for the Plants by WebSphere entity beans" providerType="Derby JDBC Provider (XA)" authMechanismPreference="BASIC_PASSWORD" relationalResourceAdapter="builtin_rra" statementCacheSize="10" datasourceHelperClassname="com.ibm.websphere.rsadapter.DerbyDataStoreHelper">
      <propertySet xmi:id="J2EEResourcePropertySet_1183122165968">
        <resourceProperties xmi:id="J2EEResourceProperty_1183122165968" name="databaseName" type="java.lang.String" value="${APP_INSTALL_ROOT}/${CELL}/PlantsByWebSphere.ear/Database/PLANTSDB"/>
        <resourceProperties xmi:id="J2EEResourceProperty_1183122165969" name="shutdownDatabase" type="java.lang.String" value=""/>
        <resourceProperties xmi:id="J2EEResourceProperty_1183122165970" name="dataSourceName" type="java.lang.String" value=""/>
        <resourceProperties xmi:id="J2EEResourceProperty_1183122165971" name="description" type="java.lang.String" value=""/>
        <resourceProperties xmi:id="J2EEResourceProperty_1183122165972" name="connectionAttributes" type="java.lang.String" value="upgrade=true"/>
        <resourceProperties xmi:id="J2EEResourceProperty_1183122165973" name="createDatabase" type="java.lang.String" value=""/>
      </propertySet>
      <connectionPool xmi:id="ConnectionPool_1183122165968" connectionTimeout="180" maxConnections="10" minConnections="1" reapTime="180" unusedTimeout="1800" agedTimeout="0" purgePolicy="EntirePool"/>
    </factories>

WASAdmin命令行管理工具
参考：
http://blog.pfan.cn/xueyb/1527.html
http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Frxml_commandline.html