IBMWebSpherePortal宕机或性能低常见问题分析及解决措施-创新互联

使用IBM WebSphere Portal构建企业门户系统是用户比较睿智的一个选择，但是由于Portal产品比较复杂，宕机或性能低也通常是用户较为头疼的问题。经常有客户门户上线后出现页面空白或无法访问，甚至宕机的问题，令人头疼不已。本文以IBM Portal常见性能低下或宕机的常见原因分析，并以笔者十几年的产品实施经验提出普众性的解决措施。

WebSphere Portal性能瓶颈通常被划分为如下八大隔离区，每个隔离区的性能低下都有可能带来用户访问速度慢、系统失去响应、空白页、页面无法显示甚至宕机的情况。如图：

接下来我们依次介绍这八大隔离区的问题点和性能优化策略：

一、Ajax异步调用等感受优化：

Ajax异步调用感受优化指的是通过技术手段，在其他方面都已经达到最佳优化的前提下，充分利用异步调用等技术，提高用户速度感受，但实质上，系统的整体性能并未提升。

（一）问题分析

这种情况通常出现在登录后进入首页时的体验上，尤其是当首页部署的Portlet比较多的时候，更有甚者，多个Portlet要调用后台的资源或者逻辑处理，每个Portlet的响应时间都比较慢，如果要等到所有Portlet初始化完毕门户首页才显示出来，那么用户等待的时间可想而知，这将带给用户非常差的体验。

（二）优化策略

IBM WebSphere Portal分为门户容器和Portlet容器两部分组成，Portal容器加载完毕后再加载Portlet容器。Portal容器加载时主要是编译并处理主题皮肤、容器运行所依赖的各种类库、数据库等资源；Portlet容器则是先有登录Portlet与Ldap通信鉴权，之后每个Portlet进入init（）方法加载各种以来提交，然后进入doService（）处理各种业务逻辑，得到处理结果并传输回门户后，统一编译成Html格式，与门户容器编译出来的Html文件共同拼装成一个Html文件呈现出来。多个Portlet完成业务逻辑并返回结果的时间长短不一，系统默认要等到所有Portlet回传完所有数据后才统一呈现。那么，响应时间最长的那个Portlet所需的时间就成为木桶上最短的那块木板。幸好，WebSphere Portal从7.0版本开始支持Ajax异步加载技术，本层处理的优化逻辑是采用Portlet异步加载技术，即使当只有1个Portlet处理完毕，也交由门户容器打包呈现出来，后续每个Portlet处理完毕后逐一加载，直至加载完毕。就用户来说，他会在较短的时间内先看到门户首页，和几个Portlet栏目，这时候用户的注意力被吸引到已经呈现出来的Portlet上面，剩余几个逐一加载的Portlet用户会降低感知，所以整体上用户的感受较好。

这是一种设计思想，需要应用到门户系统建设的各个角落。例如：首页主题皮肤部分可能设计成6张图片来回滚动，形成一个动画播放的效果。某些极端场景下例如当网络传输速度较低而6张图片的体积又较大时，如果等到6张图片完全传输完毕才加载动画播放功能，则用户感受也会较差，变通的方法是当下载第1张图片时，通过代码控制先将这张图片显示出来，然后等其余5张图片下载完毕后再执行动画播放逻辑，这样用户的感受也会大大提升。

二、JVM堆栈与Web线程池优化

JVM堆栈优化与Web线程池优化指的是Portal容器本身的JVM和其他各项参数的优化，也就是JVM容器本身以及垃圾回收策略的配置。

（一）问题分析

WebSphere Portal服务运行在WebSphere Application Server容器上的一个独立服务器，既然是JVM容器就会有大小限制。处理用户请求的每个逻辑处理都需要在JVM中开辟内存区域，用于存储暂存数据共CPU及CPU的二级缓存调取执行二进制运算。特别是有些质量不高的代码在占用内存处理完之后没有及时执行clear（）方法清空自己占用的内存，而单独依靠JVM本身的垃圾回收处理机制其处理能力是有限的。事实上，3.5G的内存是很容易被占用光的。

当已经占用的内存大于JVM本身配置的内存大小而且此时JVM还未进行垃圾回收时，就会出现没有多余的内存用来存储更多用户新增的处理请求了，这时候的表现就是新请求需要等待JVM释放内存，而JVM如果不释放内存，则用户体验就是页面一直空白，直至超时后显示“页面无法响应”、“网页无法显示”等错误，甚至Hung住或者Crash掉，这就是宕机。

（二）优化策略

WebSphere Portal服务运行在WebSphere Application Server容器上的一个独立服务器，通常64位机器上会指定JVM的大堆栈大小为3.5G，因为超过3.5G后单纯依赖JVM本身的垃圾回收机制在过大的JVM堆栈里回收执行效率反而会降低很多，这里还需要配置新生代内存的大小等。当然，如果是老式的32位机器，则JVM大大小不可超过1.8G，因为32位机器上大寻址能力就是2G而已。

同时Portal本身的多线程机制当用户访问量较大而又不能及时释放时也会好用较多的WebContainer，通常我们会将线程池个数调大10倍。如果日志中爆出“some threads is hung ，waiting for…”等类似的错误时，很可能就是线程池已经不够用了。当然，这时候我们首先得排除程序错误导致的线程池不释放导致耗尽的原因，如果排除此项，八成就是线程池个数太少导致的。而这种错误非常严重，会直接导致页面空白、页面无法显示等用户响应丢失的情况，不久就会导致宕机。

三、主题与皮肤调优

主题与皮肤优化指的是客户为了适应定制化需求，会为客户开发一套或多套门户主题与皮肤（即：Themes 和 Skins）。笔者已经遇到多家客户由于主题皮肤的问题导致系统性能低下或者宕机的情况发生了。

（一）问题分析

主题皮肤导致的性能低下或宕机主要体现在两个方面：第一，过多的主题或皮肤。很多用户为了丰富门户的视觉效果，会要求开发商开发多套主题和皮肤，几乎每张主页面都要使用单独的一套主题，每套主题下每个Portlet都要使用一个单独的皮肤。我们知道，Portal里每套主题或者每套皮肤都在单独的一个文件夹里三十多个文件拼装编译出来的。用户在使用门户系统时，多套主题与皮肤被加载，这意味着有数百甚至数千个jsp或者jspf,css,js,jpg等文件被加载进内存，太消耗系统资源了！这种情况多发生在一些对门户视觉效果要求较高的客户那里；第二、主题或皮肤文件中存在质量不高的代码，例如：有些主题皮肤里存在死循环，或者需要读取其他系统甚至互联网上的一些资源，当外围系统没有及时处理并返回结果时，主题皮肤一直在等待这个资源，如果资源没有被返回，就得等到超时，如果超时了都在等待的话，就很明显地出现页面空白或显示不出来了。

（二）优化策略

笔者强烈建议，能通过一些参数化的方式解决的问题尽量通过参数化的方式，例如多个部门门户的主题皮肤使用同一套主题，通过参数化主题上的Logo图片，参数化文字等方式实现各个部门门户网站的显示效果差异；同样的，每套主题尽量不要超过5套皮肤，还是通过参数化的方式来进行Portlet不同风格的呈现。

至于主题皮肤代码层面，建议项目组花大力气严格检查有没有存在死循环、读取大数据量、不及时释放内存等低质量代码、等待依赖系统响应等低质量逻辑。对不懂代码的客户来说如果要采用逆推的方式判断是否存在代码质量的情况，则可以使用LoadRunner对系统进行抗疲劳测试，通过耐压测试，让系统低质量代码对内存、CPU等的消耗和侵占尽量表现出来。鼎亚科技可以为全国的用户×××能调优方面的免费培训和压力测试方面的指导、培训。

四、SQL执行效率优化

门户性能低或者宕机问题不仅仅是由于内存耗尽导致的，还有CPU和硬盘。SQL执行效率是同时可能对这三方面造成损耗的重要因素之一。

（一）问题分析

SQL执行效率的损害通常体现在如下两个方面：（1）SQL慢查询或者语句执行大数据量的查询并返回了大数据量的查询结果，例如某客户一下子查询出4000万条用户登录记录并打印在了主题文件里，这些大数据量既会占用内存，又会消耗CPU，甚至写入一些硬盘文件，天长日久导致硬盘被占满而宕机。SQL慢查询则会带来大量的用户等待时间。（2）SQL语句执行次数过多或死循环。系统要查询一组数据时，需要到多张表里执行多组查询并拼装处理返回的结果，或者某些极端条件出发SQL执行死循环，既消耗大量的CPU资源又不返回结果，宕机也就是不可避免的了。

（二）优化策略

务必通过强壮的代码审查（Code Review）识别出SQL慢查询、大数据量查询、死循环等问题，并合理设计表结构，合理设计SQL语句。与上一节相同，对不懂代码的客户来说如果要采用逆推的方式判断是否存在代码质量的情况，则可以使用LoadRunner对系统进行抗疲劳测试，通过耐压测试，让系统低质量代码对内存、CPU等的消耗和侵占尽量表现出来。鼎亚科技可以为全国的用户×××能调优方面的免费培训和压力测试方面的指导、培训。所谓的抗疲劳测试指的是，录制尽可能覆盖所有页面、所有逻辑的功能点，并设置LoadRunner在没有思考时间的前提下，进行长达72小时的耐久性测试，所谓“日久见人心”，哪怕SQL执行效率稍微有一点点低下，资源有一点点没有及时释放的，通过高强度的耐压测试，也会让问题无限放大，最终暴露出来。

五、数据库性能优化

数据库性能优化指的是数据库本身的参数优化，以及WebSphere使用数据源连接池的参数优化。

（一）问题分析

IBM WebSphere Portal使用数据源连接池即长连接的方式提供数据库服务，所以不合理的数据源连接池配置会导致数据库处理逻辑等待时间过长或者宕机。例如：如果某些Portlet应用频繁读取数据库，而连接池的个数过低，就会有大量的数据库读写逻辑在排队等待数据库连接，甚至超时后导致宕机，最直接的后果就是用户的很多Portlet应用一直初始化不出来，原因是在等待其他逻辑释放数据源连接池后进行数据库读写操作。

（二）优化策略

通常我们会在WAS控制台上配置数据源连接池的个数为系统默认的3-6倍，具体视各家客户的门户内容使用数据库的频率高低而定。数据源连接池个数过低，会造成Portlet逻辑排队等待拉长响应时间；个数过高则会导致系统可用内存降低，因为每个数据源连接池会占用大约3M左右的内存，如果配置几百个数据源连接池，则仅仅数用于数据库连接的内存就会占用1个多G，计算我们配置了3.5G的JVM，也没剩多少计算内存用于门户的逻辑处理，同样也会导致系统的性能降低或宕机。这里还要强调数据源连接池的过期时间，不恰当的TimeOut也会带来等待响应或系统无法处理用户的正常请求。最准确的个数配置来源于最佳实践。直白的说，就是通过设置不同的参数后进行合理配置的LoadRunner压力测试，压力测试场景的设计尽量贴近用户使用的真实场景，来模拟生产环境的真实状况，然后通过对比LoadRunner压力测试表现最好的那组，确定数据源连接池的最佳配置。

额外的，通常数据库服务器和门户服务器是不同的服务器，中间架设防火墙的客户比例非常高，这里我们要强调一下一定协助客户合理配置防火墙策略，因为防火墙切断门户与数据库之间的长连接而导致的门户宕机案例非常之高。

六、数据/数据集优化

数据与数据集优化指的是无论Portal容器还是Portlet容器读写的数据量大小问题，数据量过大会消耗大量时间和空间资源，会导致系统性能低下或宕机。

（一）问题分析

Portal主题皮肤里的代码和（或）Portlet应用逻辑代码在执行大数据量操作时，会消耗大量的时间资源、空间资源；时间资源体现在CPU处理上，空间资源体现在内存占用上。无论是CPU过于繁忙还是内存消耗过大都是一种危险的事，最常用的就是分段读写、分页显示、大数据转移等问题。

（1）大数据量读写。数据库执行大数据量读写时，会消耗大量的CPU时间和内存占用，用户并发量一上升，就很容易导致性能问题。

（2）分页显示。这个无需多说，用户通常看的是前3页，如果一下子把几百页读取过来，内存空间的占用是巨大的。

（3）大数据转移，指的是某些表里可能存储非常大量的数据，例如用户登陆日志，数据积累越来越多，读写速度就会越来越慢，系统资源消耗就会越来越大，性能也就越来越低了。

（二）优化策略

针对于常见的这些问题，分别介绍调整策略。这部分其实最多的也是与常规Java开发相同，请自行参考。

（1）分段读写指的是，逻辑代码在读写数据时，尽量不要大数据量读写，例如向数据库或文件系统中一次写入超过10万条数据，或者读入上百万条数据，这种效率肯定极低，尝试修改设计，优化读取逻辑。

（2）分页显示。这个无需多说，每次读写最多3页，等用户点击翻页时再读取更多的数据。

（3）大数据转移。适用于某些表里要存储大数据量时，最好不要超过千万条记录的级别，通常用在用户登录日志等，随着使用时间的推移，表中的记录条数越来越多，读取的时候也很容易消耗资源。

七、Portlet代码与逻辑优化

Portlet开发实际上与传统的Java开发并无二致，Portlet等待数据库连接、死循环等带来的系统性能低下，成为Portlet层面优化的问题本质。

（一）问题分析

Portlet代码导致性能低下的情况通常有：（1）执行逻辑效率低或死循环导致Portlet响应异常地慢，例如要到十几套系统里读取各个系统的待办信息等；（2）Portlet等待某些资源而这些资源没有及时加载或者压根就加载不出来，而Portlet端有没有处理读取不出来时候的出错处理，导致Portlet一直在等待资源，系统线程Hung住也就很正常了。

（二）优化策略

这需要合理设计Portlet实现逻辑。例如：统一待办Portlet，我们可以采用逆向推送的方式，当各个业务系统产生新的待办事项时，主动推送到门户缓冲数据库（可以认为是Broker层），然后Portlet直接到缓冲数据库一个表里读取待办条目，这样可以提高Portlet性能达数十倍。

第二，通过严格的代码检查消除Portlet中资源等待、死循环等问题。这个问题的检查与普通的Java开发并无二致，本文不再赘述。

八、网络传输（包大小）优化

显示逻辑和打包逻辑优化多发生在网络速度不太高的客户场景中，尤其是部署在云端或者互联网上的客户，指的是过大的数据量传输导致了用户响应时间太慢，慢到用户以为系统宕机了。备注：如果传输时间超时，那就真宕机了。

（一）问题分析

我们知道，所有用户的请求都是通过服务器端唯一的网线出口与用户的客户端电脑（或手机）建立比特流传输的。建设每个用户访问门户需要传输3M的数据流量，这3M包含了逻辑处理完成之后编译出来的css文件，jss文件，html文件，jpg/png等图片文件，假设有300个用户在并发访问，则这300个用户一共需要传输3Mx300=900M数据流量。如果我们服务器申请的带宽是百兆，也就是每秒钟能传输12.5M数据，则即使出去逻辑处理的时间，进网路传输的消耗，就需要900M除以12.5M/S等于72秒，这是一个多么庞大的数据，每个用户光等待传输就要等待72秒

（二）优化策略

在不影响图片观看效果的情况下，我们建议用户尽量降低图片的大小，对程序开发者来说，在不影响功能的前提下，尽量为js文件、css文件等减肥，将其体积降到最低，尽量降低网路传输带来的用户体验消耗。作为系统架构师或项目经理，要充分调研，充分考虑到真实的用户并发情况，并协助用户购买或分配合理的网络带宽。