聚沙成塔-小哈的记事薄

为什么要介绍WAS CE

公司开发的产品几乎都是三层B/A/S结构，生产环境中使用WebSphere Application Server作为中间件的不少。但是限于个人开发机器的性能限制，开发过程中开发人员大部分是基于Tomcat环境实施项目开发，之后将应用程序发布到正式环境——WebSphere Application Server上，而Tomcat与WAS在规范细节上的标准差异，以及对第三方组件支持的区别，导致很多应用迁移到正式生产环境上遇到各种各样的问题。所以本文介绍IBM WebSphere Application Server家族的一款免费的轻量级中间件产品——WebSphere Application Server Community Edition，建议今后有新项目，且明确最终环境是WAS中间件时可以在开发时使用。

WAS CE简介

IBM WebSphere Application Server Community Edition 是在 Apache Geronimo（Apache Software Foundation 的开放源代码应用程序服务器）的基础上构建的 J2EE 应用服务器。

WAS的优点

支持全面

WAS CE21完整支持Java EE5.0，并向下支持j2ee1.4；支持各种数据库；Web2.0的各种特性

J2EE Version 5 编程模型采用 Apache Geronimo（Apache Software Foundation 的开放源代码应用程序服务器项目）技术。Apache Geronimo 将各个主要开放源代码社区的最佳技术组合起来，以支持 J2EE 规范，这些技术包括：

• 用于支持 Servlet 和 JavaServer Pages (JSP) 的 Apache Tomcat
• 用于支持 Enterprise JavaBeans (EJB) 的 OpenEJB
• 用于支持 Java Message Service (JMS) 的 ActiveMQ
• 用于支持 Java Management Extensions (JMX) 的 MX4J
• 用于支持 Java Database Connectivity (JDBC) 的 TranQL
• 用于 Web 服务的 Apache Axis
• 用于 Java Transaction API (JTA) 的 HOWL (ObjectWeb)

WebSphere Application Server Community Edition 支持 IBM 和 Sun 的 Java 开发工具包 (JDK)。

可以看到WAS CE是Tomcat的超集，它使用 Apache Tomcat 作为缺省 Web 容器，还集成了诸多Tomcat所没有的特性。特别是比较常用的Apache Axis，省去了自行调用Axis发生的各种BUG。

安装方便 运行要求低

采用 InstallShield 按需安装，下载包占用空间小。从核心组件到完整下载，大小为85M～191M

下载地址 http://www.ibm.com/developerworks/cn/downloads/ws/wasce/

可以选用不同的JDK，可以根据今后部署的平台来选择。比如今后WebSphere安装在PC Server或者IBM小机上，那么就选用IBM JDK；安装在HP的小机上，那就选用HP JDK

开发工具的支持

Eclipse 插件
该插件使您可以利用基于 Eclipse 技术的 Web 工具平台来提供简单的开发环境，以便创建、部署和调试 WebSphere Application Server Community Edition 应用程序。

http://download.boulder.ibm.com/ibmdl/pub/software/websphere/wasce/updates/

简单而又全面的管理控制台

Tomcat一般不使用管理控制台，而是直接修改配置文件，需要对配置文件了解比较多，而WAS CE则有一个强大的管理和开发控制台，包含诸多工具用来配置和发布应用；配置数据库连接，修改web.xml等等，更重要的是这一切都可以通过向导来完成。

方便迁移

使用 Application Advancement Assistant工具，可以方便的把WAS CE上开发的应用程序迁移到WebSphere Application Server V6.1上去

工具下载地址http://alphaworks.ibm.com/tech/wasma/download

迁移示例

将 WebSphere Application Server Community Edition 应用程序方便地迁移到 WebSphere Application Server

WAS CE和WAS属于同一家族产品，迁移过程中的问题较之使用Tomcat，肯定会大大减少，最重要的是，使用这个工具，就算遇到问题也可以显示出问题出现在哪些地方，方便定位。

简单集群和故障转移的支持

现在很多项目正式运行都是用WAS ND版做了WAS的集群来提高可靠性，但是基本上程序开发时都是考虑单机环境。WAS CE支持web层的负载均衡和故障转移，可以在开发时就考虑到如何更好的利用集群环境。

丰富的文档支持

IBM产品的一大特点就是文档丰富，可以给开发人员极大帮助。

WAS CE的开发社区

http://www.ibm.com/developerworks/spaces/wasce?S_TACT=105AGX01&S_CMP=LP&pageid=710

里面有支持与文档、示例与工具、技术文章、迁移资源等子栏目，可以解决开发过程中遇到的疑难杂症。

WebSphere Application Server Community Edition V2.1 文档，如果纯属使用WASCE的问题，可以先到这里找到快速解决方案

http://publib.boulder.ibm.com/wasce/V2.1.0/zh_CN/index.html

WebSphere Application Server Community Edition 专栏 ，WAS CE在IBM developworks上的专栏，里面有翻译好的专栏文章。

IBM 800 Support

作为免费的Tomcat，缺少技术支持是它不能很好的作为商业运行平台的一个重要因素。JBoss虽然有支持服务，但是它需要每年花费16000美元来购买管理控制台，并且每4个CPU每年另加6750美元（For deployments of under 32 CPUs JBoss requires separate purchase of the admin console support for $16,000 / year in addition to the $6,750 / year for each 4 CPUs ）。相比较而言购买WAS CE的支持则优惠很多。

结束语

上述是我对开发过程中中间件的选用的一个建议，如果今后项目是WAS平台，各位项目经理可以考虑使用WAS CE作为开发平台。至于WAS CE开发的应用程序能否无缝迁移到Weblogic，开未作研究。

WAS CE21的PPT，有兴趣的可以仔细阅读一下。http://docs.google.com/Presentation?docid=dgqfmsbr_1gvbmbjth

前言

What is the Cause of the Performance Problem? 或者是How to Improve the Performance?

这是我们在系统开发、部署过程中都会面对的问题，但是却很难回答。从下面的这幅图就可以看到，一个系统的性能瓶颈（bottleneck)，可能在网络、防火墙，也能在Http Server，Application Server，或者是数据库；系统中一个或者多个“短板”的存在，就能让系统无法达到设计时的目标，无法满足已经签在合同里的SLA……

虽然性能问题牵涉到方方面面，但是本系列关注点在于中间件这一层。希望能用合理的配置避免诸如OutOfMemory（某些情况下）、数据库连接不够的发生，同时能应用一些参数使系统在不优化代码的情况下有5%到100%的提升。

言归正传

池（Pool）是WebSphere中最常涉及的概念之一。从网络、Web 服务器、Web 容器、EJB 容器，一直到数据源，每一个环节都线程池、连接池的影子。要想恰当配置这些池的大小，首先要了解漏斗模型。

通常，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。

那么实际生产环境中就如此依样画葫芦就可以了么？后面的池一定比前面的小么？如果当前性能不行，增大池的大小就能提高么？

绝没有那么简单。后面的池小于前者，比如数据库连接池小于web线程池，默认的假定是：并非每个JSP和Servlet都需要访问数据库。如果你的应用是数据库密集型的应用，基本上每个JSP和Servlet都需要访问一次或多次数据库，而且系统中还有一些不经过jsp或Servlet的后台进程。那么数据源的连接池就必须大于web容器线程池，否则会报无法得到连接的错。

下面按照我的经验讲述一下每层池大小设置值

对于Web服务器

IBM HTTP Server的优化就是对Apache的优化。一般需要调整httpd.conf中如下参数：

MaxClients：用来定义Web服务器可以同时支持的最大并发连接数或并发用户数，默认值是600。这个值需要根据你所希望的同时支持的并发用户数来设置，一般是峰值的120%。当然这个值不能设的太大，毕竟Apache吃内存也是很厉害。我遇到的项目一般是不用调整的，大家可以根据实际负载动态的调整MaxClients。

将 IBM HTTP Server 配置为显示状态页面：

• 编辑 IBM HTTP Server 的 httpd.conf 文件，从此文件的下列各行中注释注释字符（#）：

  #LoadModule status_module, modules/ApacheModuleStatus.dll,
  #<Location/server-status>
  #SetHandler server-status
  #</Location>

• 保存更改，然后重新启动 IBM HTTP Server。
• 在 Web 浏览器中，转至 http://yourhost/server-status。并且，单击重新装入以更新状态。
• （可选）如果浏览器支持刷新，那么转至 http://your_host/server-status?refresh=5 以便每 5 秒钟刷新一次。

上图给出了一些其它参数的推荐值。注意Windows平台和其它平台的不同（ThreadsPerChild相当于Maxclients）。关于MinSpareServers, MaxSpareServers, 和StartServers 等的设置，以及MPM使用prefork或worker模块时的不同，可以阅读Apache Performance Tuning。

如果你的应用访问量很大，那么也许你需要优化一下操作系统的tcp/ip相关参数。 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html

并修改“负载均衡”选项和“重试时间间隔”Web 服务器插件属性设置以提高性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html

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%，那么可以肯定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。

这篇文章也许会使你对线程池大小对性能的影响有个感性的认识。

设置的地方大家应该都晓得，单击服务器 > 应用程序服务器 > server_name > 线程池。

数据库连接池

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

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

Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：

• 如果运行包含三个服务器的集群，这三个服务器都使用 myDataSource，并且 myDataSource 的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）

这是需要考虑的，别数据库端的连接大小不够了。此外，inactive timeout和timeout的时间应该大于收集时间。

总结

这篇文章参考了IBM的inforcenter和developworks，给出了优化WebSphere池大小的一些经验值，但是真正合适的大小还要参考实际的情况，总之调优是个循序渐进的过程。

继续逛逛

调整完了各种池的大小，接下来你需要对内存参数做些优化，这篇是纲领性的。

JVM的恩恩怨怨-WebSphere性能优化（二）

针对不同的JDK，你可以参考：

JAVA性能优化—Sun Hotspot JDK JVM参数设置

JAVA性能优化—IBM JDK JVM参数设置

有了最早的安装WAS6.0和上两篇文章的介绍，接下来安装集群的过程其实很简单。

对于新安装的集群：

1. 安装WAS主程序并升级补丁
2. 建立Deployment Manager profile
3. 新建两个Custom profile，建立过程中就完成联合节点工作
4. 启动两个node中的nodeagent
5. 进入控制台，新建集群，分别在两个节点添加application server

如果新建Custom profile时出现问题，或者更多的情况是想把原来已经建立好的，带有应用的application server profiles联合到DM中来建立集群，那么：

1. 安装WAS主程序并升级补丁
2. 建立Deployment Manager profile
3. 新建两个application server profile（或者原先已经有了）
4. 到profiles/bin目录下执行addnode命令：addnode DM所在IP或主机名 8879（端口）-includeapps（如果有应用的话）-username {用户名} -password {密码}
5. 启动app profiles下的nodeagent
6. 进入控制台，新建集群，用已经存在的application转化为cluster的member

复习一下安装profile的过程

安装DM profile

建立application server profiles

看一下如何新建集群：注意先运行addnode命令，然后启动node agent

看明白了么？没琢磨清的来这里：WebSphere v5 ND在AIX环境中安装和配置

WebSphere V7.0在Windows下的集群配置

还有一份在Unix/Linux下配置V6.1的集群文件比较大，Google Docs无法上传，其实和V7.0没有差别，照着V7做就可以了。传到了纳米盘，《WebSphere v6.1 ND在Unix&Linux环境中安装和配置》，由IBM应用开发合作中心撰写。步骤清晰，图文并茂，最重要是中文。从WebSphere Application Server、IHS、Plugins的安装配置，到WebSphere集群的搭建、节点代理程序（Node agent）的起停方法、如何生存和传播Webserver插件，回话（Session）复制，如何安装补丁。居家旅行必备文档啊

WebSphere v6.1 ND在Unix_Linux环境中安装和配置.pdf

微软的SkyDrive的嵌入方式使用的是iframe，wordpress在2.2之后就不支持iframe语法，所以大家点进去下吧。

紧接上文，我们了解了Application Server，profiles，Managed Node、Umanaged Node等概念，知道了最简单的stand-alone拓扑结构。那为了弥补stand-alone模式的可扩展性（Scalability）可靠性（reliability）要求，有必要提出Cluster的解决方案。

       这副图里我们可以看到分布在两台Machine上的两个Node，每个Node含有三个Application Server，其中两个Server与另一个Node中的两个Server构成了Cluster，这个Cluster通过Node agent被一个Deployment Manager管理。同时我们可以看到每个Node另有一个单独的Application Server，这个Server和之前介绍的Stand-alone application server可以看作是等价的，只是现在被加入到Network Deployment中，接受DM的统一管理。整个的绿色大背景则是一个单元（Cell）。

术语四 Deployment Manager（DMgr）：在分布式拓扑中管理一个或多个节点的特殊profile，通过Node agent把配置和管理动作传达到每个Node中的Server上。可以通过PMT工具建立DM profile，它包含了主配置库，以及各个节点上有的配置文件——启动这个节点所需的XML配置和应用程序文件 。由此可见，各个节点的配置文件是DM上有的子集，所以当我们修改节点上应用里WEB-INF下的诸如web.xml文件，除了在节点上的config目录中要做相应修改，DM节点上config目录里同样要修改，否则重启dm后，一切配置信息将同步到和DM里有的状态。

术语五 单元（Cell）：是一个逻辑上的管理域的称呼，提供了对节点的单独管理入口，这个域由跨多台主机上的Node和一个DM组成，

了解了以上这些术语，那集群的概念就很简单：集群就是一组多个Application Server组成的group，运行着同样的应用程序。一个集群可以运行在一个Node上，或者同一台机器的不同node上（垂直集群），可以运行在不同机器的不同Node上（水平集群）。由此提供故障转移。配合web server，则能做到负载均衡。

有了这些概念，再大的Topology都不怕。

下文将讲述建集群的详细操作步骤。

/**   下文是我根据自己一年多的工作经验，结合IBM的PPT写成，如果你觉得表述的不是很明白，可以前往阅读IBM官方文档IBM WAS ND 分布式网络环境的理解与集群的实现。**/

在Websphere入门篇（一）-was6.0安装中，我们配置了一个Websphere Application Server，前端联合了一个Http Server，后端连接Oracle数据库。这是WebSphere最简单的拓扑结构——带Web服务器的单机环境（Stand-alone Application Server Topology with Web Server ）

Stand-alone Application Server拓扑方式的安装是指在一个单独的节点上（Node）运行一个（仅能一个）Application Server进程的安装方式。如果你需要多个Application Server，那么你就要起多个profiles，而在ND环境中一个Profile可以起多个Application Server。在Stand-alone的环境下，Web服务器只能定义一个，ND环境下则无此限制。

术语一 Application Server：一个为J2EE应用提供了web容器、EJB容器、Naming、JMS等服务，同时提供配置和管理功能的运行平台。在Windows、Unix等分布式操作系统上，一个Server单只一个JVM实例，我们看到的就是一个java进程；但在z/OS平台上，一个Server可以包含多个操作系统进程，每个进程都单独运行一个JVM实例。

术语二 WebSphere profiles：一个application server所需要用到的User files的集合，包括诸如环境变量是如何设定的、各种资源是如何配置的、日志文件的记录格式……所有的这些构成了application server的运行时环境。

与之相对应的是Product files——运行application server所需要的二进制文件，这些二进制文件是各个profiles共享的。因为只有这一份二进制文件集，所以websphere代码的变更，比如补丁的升级，可以被旗下所有的profiles享用到，无需为每一个Profiles单独操作，节省了磁盘空间。

由此可知，如果需要为不同的应用使用不同的补丁版本，或者为某个应用打一个小fix，那么只能重新安装一个完整的WAS程序，而不仅仅是单独建立一个profile。而不同机器间WAS的迁移，也必然不能简简单单的拷贝WAS安装目录了事，至少需要安装WAS程序，profiles因为是配置的集合，和机器的相关性比较小——主机名、端口号等配置还是需要注意的——可以“偷懒”拷贝一下。

术语三 节点（Node）：节点是受管服务器（Server）的逻辑分组。节点通常与具有唯一 IP主机地址的逻辑或物理计算机系统对应，节点不能跨多台计算机。

分为Managed Node：可以被Deployment manager管理，在ND环境下的application server必然是Managed Node，同时也会有一个对应的Node agent，通过在profile name/bin目录下运行startNode命令，可以让DM来管理application server。当一个Stand-alone的application server联合到ND环境下时，Node agent会自动生成，当然之前是没有的。

与之对应的是Unmanaged Node：顾名思义是无法直接通过DM来管理的节点，一般是作为Web Server所在节点存在的，特别是当Web server位于DMZ区，而app server位于防火墙之后。虽然是Unmanaged Node，但是生成插件、传播插件是可以的，只是起停web server需要手动执行。

摘自WebSphere Application Server 常见问题及解答：什么是单元（Cell）？什么是节点（Node）？Node、Profile 与 Server 之间的关系是什么？

如果stand-alone的结构无法满足应用程序的可扩展性（Scalability），可靠性（reliability）要求，那么我们就需要使用Network Deployment Topology，进而配置Cluster来满足以上两个要求。具体见下文。