引用 ： http://bbs.langsin.com/thread-56115-1-1.html
IBM WebSphere Portal 6.1项目实施与开发、配置技巧集锦
1.1 更改Portal默认的登录选项
1.1.1 问题描述
登录Portal6.1成功后，是跳转到系统指定的默认页面呢？还是恢复用户上次退出时所在的页面？还是由用户自己选择以上两种方式中的一个，即：取决于用户登录时的选项？
我们通过以下这个例子来说明如何调整：
假设我在门户有两个页面，一个首页，可以匿名访问，里边有login的portlet，还有一个个人页面，需要验证。
在首页登陆成功后还在首页，不能自动跳转到个人页去。。。
请问能不能实现从首页的登录portlet成功登录后，自动跳转到个人页。
1.1.2 解决方案
第一种方法：WAS中添加参数法
1 建立URL MAPPING：
在管理页面中，选URL映射
点击“新建上下文”按钮
输入一个标签名，点击确定。
点击右编辑映射图标。
将要跳转的页面选中，点击确定。
此时在地址栏输入http://ip:port/wps/myportal/test就可跳转到TestPage页面。
2 配置WP_CONFIGSERVICE
进入WAS控制台，选资源--》资源环境--》资源环境提供程序
点击WP_ConfigService
再点击右边的定制属性
点击新建按钮，加入redirect.login=true,redirect.login.url=http://ip:port/wps/myportal/test
保存后重启PortalServer即可。
第二种方法：修改登录页面代码直接重定向法
找到简单的方法了，在LoginView.jsp中的form里处加入
<input type=hidden name="WPSRedirectURL" value="/wps/myportal/personal"/>
都不用重启服务器，刷新下页面就可以了
1.2 获取登录用户信息
1.2.1 问题描述
获得登录用户对象，并取出用户名、注册邮箱等用户信息无论在主题与皮肤开发，还是Portlet开发中都经常会用到。如何取出用户信息？我们通过配置加编码的方式实现：
1.2.2 解决方案
第一种方法：标签+代码方式：
首先修改
IBM/WebSphere/wp_profile/installedApps/[cellname]/wps.ear/wps.war/themes/html/ThemeName 目录下的Default.jsp文件：
1 将<%@ page session="false" buffer="none" %>改成<%@ page session="true" %>
导入ibm user的jar包,这个包的名字是wp.user.api.jar,
可以在IBM/WebSphere/PortalServer/base/wp.user.api/shared/app下找到。
<%@ page import="com.ibm.wps.puma.User" %>
加入如下代码
<%
HttpSession mysession=request.getSession();
String loginname="";
if(mysession.getAttribute("com.ibm.wps.util.session_user")!=null){
com.ibm.wps.puma.User myuser=(com.ibm.wps.puma.User)mysession.getAttribute("com.ibm.wps.util.session_user");
loginname=myuser.getFullName();
}
%>
第二种方法：
<%@ page import ="com.ibm.portal.portlet.service.PortletServiceHome" %>
<%@ page import ="com.ibm.portal.portlet.service.PortletServiceUnavailableException" %>
<%@ page import ="com.ibm.portal.puma.User" %>
<%@ page import ="com.ibm.portal.um.PumaHome" %>
<%@ page import ="com.ibm.portal.um.PumaProfile" %>
<%@ page import ="com.ibm.portal.um.exceptions.PumaException" %>
<%
PumaHome home = null;
Context ctx = new InitialContext();
PortletServiceHome serviceHome = (PortletServiceHome)ctx.lookup("portletservice/com.ibm.portal.um.portletservice.PumaHome");
home = (PumaHome)serviceHome.getPortletService(PumaHome.class);
PumaHome pumaHome = home;
PumaProfile pumaProfile = pumaHome.getProfile();
String currentUserName = null;
User currentUser = (User)pumaProfile.getCurrentUser();
currentUserName = currentUser.getName();
out.print(currentUserName );
%>
1.3 个性化Portlet添加控制板
1.3.1 问题描述
正常情况下，我们会按照如下的方法使用Portlets添加班来工作：
以wpsadmin登录Portal6.1，点击页面右上角的三角形按钮；
可以看到portlets选用板被成功初始化：
通过将板上的portlet拖曳到左侧页面，可以直接将Portlets定制到页面，并分配给相关权限的用户使用。
点击Portlet列表的分类选项条目的右侧，可以查阅该分类下的所有portlet。
这时候有人就可能提出问题了：这些分类都是默认的，难以识别。能不能按照我的类别分类？并且将我希望提供给用户添加的portlets添加到相应的类别里？
回答是肯定的。以下是解决方法
1.3.2 解决方案
点击“Portlet”选项右侧的三角形下拉框，选择“配置”
点击各个类别右边的三角形，选择“删除类别”，这个类别就被删除了。
如果选择“重命名类别”还可以给这个类别改名称。
如果点击“配置”右侧的“添加新类别”，就可以创建新的类别了。
点击创建好的新类别右侧的“添加portlets”，就能为这个类别分配属于该类别的portlets。
当然了，如果您的类别被您弄得一塌糊涂，而您又想恢复为系统刚刚安装完成时的默认状态，那么您可以选择配置右侧的“复位缺省设置”，那么，您所个性化的所有类别都将被删除，系统会替换成刚刚完成安装时的默认状态。
这里介绍比较简单，还有很多其他的用法，您都可以试试。
1.4 Portal6.1.0.3在windows平台安装或升级失败
1.4.1 问题描述
Portal6.1.0.3在windows平台上安装或升级失败。已经安装Portal 6.1.0.1或者6.1.0.2，试图升级到6.1.0.3，发现在windows平台上升级失败。
检查升级日志，例如20100122_135338_WP_PTF_6103_selective-install.log文件，发现与PeopleFinder有关，系统在安装peoplefinder_portlet期间发生错误导致。
检查people_finder portlet install日志，
20100122_135338_WP_PTF_6103_people.impl_._peoplefinder_._portlet_install.log：
发现是由于安装过程中两个文件的属性并定义成了只读属性，无法取代导致的。可以肯定的是，系统安装完成后，没有手工去改过这两个文件的属性，怀疑是升级程序篡改了文件属性。6.1.0.3升级程序刚刚推出没多久，出现这种可能的错误也是正常的。
1.4.2 解决方案
登录Portal6.1.0.3的安装目录，找到这个路径：
D:\IBM\WebSphere\PortalServer\pcc.impl\people.impl\peoplefinder\portlet\lwp_peoplefinder_war.ear\lwp.peoplefinder.jsr168.war\html\
查看help目录的权限，发现果然是只读的。
修改该文件夹属性，确保该文件夹及子文件、子文件夹不是只读属性。
重新安装补丁包，安装成功，系统成功升级到6.1.0.3。
1.5 使用was6 dynomic Cache机制提高wcm content view portlet性能及响应速度
1.5.1 问题描述
WCM模块的速度之慢是众所周知的。除了保证业务逻辑上的连贯性之外，使用Cache技术也是提高wcm内容展示的一个好思路。
假设我们使用wcm authory构建了有100多个站点区域的站点，然后我们自己开发content view portlet来依据参数分别展示这100多个站点区域到100多个栏目。
接下来我们将采用适当的WAS6 dynomic Cache(was6 动态缓存)机制来提高wcm content view的性能及响应速度，这是充分利用portal6.1所使用的JSR286容器优势的一个绝佳方法。
1.5.2 WAS6 Dynomic Cache解决方案
1. 在你开发好的portlet中创建 cachespec.xml 文件来定义动态缓存。
2. 创建一个javabean来生成合理的CacheID。
3. 安装该Portlet并重新测试，验证是否缓存起效。
1.6 关于压力测试需要注意的几个问题
1.6.1 问题描述
系统正式上线之前我们需要对portal系统做压力测试，模拟真实用户登陆，以便测试我们的系统上线是否存在风险。
设计系统压力测试时，我们需要注意以下几个问题。
1.6.2 解决方案
1.6.2.1 设计合理的并发压力值
估算一个用户请求可能会消耗的系统内存，例如：3M。确认WebSphere_Portal服务器分配到的JVM内存，例如：1536M。减去维持系统基本运行时环境所需的基础内存，约600M。实际上此时系统用户计算的可用内存为1536M-600M=936M。那么我们本台服务器能支撑的并发用户数为：936/3=312用户。此时可以设计测试场景的并发用户数为312用户。当然，如果您采用的是集群环境，那么可以乘以节点服务器个数。例如您的集群石油3个portal服务器组成的，那么您设计的portal并发访问数就可以为312*3=936并发。
足够的并发满足后还要进行抗疲劳测试。因为我们可能会发现很多系统在刚上线的一两个月里是没有任何问题的，但是过段时间可能或出现内存溢出或者内存泄露的问题。这通常是由于系统存在一些问题，这些问题每天都会占用一些系统资源例如内存不能释放出来，时间一长，积累的越来越多，问题就会暴露出来。所以在测试时我们尽量设计脚本和场景运行时间更长一些，例如连续压力测试24小时，以便模拟真实的环境用户使用了半年甚至更久。
再次，我们还需要故意设计一些错误的场景，因为，我们可以要求用户不做出错误操作，但是我们却无法避免用户不实际做出错误的操作来。系统能不能对用户的错误或者失误操作进行容错，也是测试系统功能的一个要点。我们尽量提前先把用户的错误模拟出来，以便验证系统的容错性能。
1.6.2.2 不得使用同一个用户ID在同一机器或多台机器上同时多次登录
有时候测试时，用户可能无法提供那么多的真实用户名和密码，例如上面的例子，我们需要用户提供936个真实用户的用户名和密码，而这通常是不现实的。很多项目组就决定使用其中的50或者100对用户名/密码模拟真实的936个用户，实质上这是不允许的。
IBM WebSphere Portal严厉禁止同一ID同时多次登录系统，不管是在同一台机器上还是模拟出多个ip来，这将会导致不可预知的后果，甚至系统崩溃。
对应中文的信息中心也对该问题有了明确的定义：
1.6.2.3 Portal XAException异常
点击“Portlet”
1.6.2.4 Portal XAException异常
点击“Portlet”
1.7 Portal6.1.0.3无法查找任何的用户或用户组
1.7.1 问题描述
系统升级到6.1.0.3之后，发现无法搜索任何的用户或者用户组，这体现在的功能模块有：wcm授权，wcm管理，pdm管理，凡使用到people picker page的地方，都无法使用。
1.7.2 解决方案
这是由于portal6.1.0.3的升级程序可能不慎修改了people picker portlet的属性值，这导致了该portlet无法查找到合适的用户或用户组，我们必须手工去修正这个问题。修正该问题的步骤是：
1. 以was超级管理员（一般式wpsbind）登陆was管理控制台。
2. 点击 “资源”—“ 资源环境”—“环境资源提供程序”，找到“WP People Service”条目
3. 点击 “Custom properties（自定义属性）”,编辑以下三个属性值:
4. 要确保这三个值与您的LDAP中的属性相对应。例如：
5. 重启Portal服务器，验证是否已经可以正常工作。
第2章 操作系统管理策略
2.1.1 限制应用程序对CPU的使用率
2.1.1.1 安装WLM (Workload Manager)设置步骤
环境:RS6000,pSeries AIX
问题描述:
客户需要限制某些用户CPU和内存的使用率,可以通过设置WLM (Workload Manager)来实现.
解答:
步骤如下:
1.smit wlm
2.添加 class:
选择Add a class
Class name ftp
Description [cpu mem Intensive]
Inheritance [Yes]
Localshm
[Yes]
3.添加规则,
选择"Class assignment rules"
Create a new Rule
添加监控的用户,组以及应用的所在目录
Order of the rule 1
New Order of the rule [1]
Class name ftp
User [root]
Group [-]
Application [/usr/sbin/ftpd]
Type [-]
Tag
[-]
4.显示class
System
Default
Shared
ftp
5.Change / Show Characteristics of a class
指定cpu限制
CPU resource management -->
Class name ftp
Shares [-]
Minimum (%) [2]
Maximum (%) [5]
Absolute Maximum (%) [5]
指定memory限制
Memory resource management -->
Class name ftp
Shares [-]
Minimum (%) [2]
Maximum (%) [5]
Absolute Maximum (%) [5]
6.启动 WLM
smit wlm -->
Start/Stop/Update WLM -->
Start Workload Manager
Configuration, or for a set: set name/currently current
applicable configuration
Management mode active
Enforce Resource Set bindings Yes
Disable class total limits on resource usage Yes
Disable process total limits on resource usage Yes
Start now, at next boot, or both ? Now
7.验证WLM是否生效:
ftp 到服务器,执行以下命令:
put "|dd if=/dev/zero bs=32k count=10000" /dev/null
8.用命令检查WLM是否生效
wlmstat命令
#wlmstat
CLASS CPU MEM DKIO
Unclassified 0.00 27.93 0.00
Unmanaged 0.02 44.54 0.00
Default 0.12 6.43 0.00
Shared 0.00 3.12 0.00
System 14.38 50.05 0.00
ftp 0.00 0.01 0.00
TOTAL 14.50 87.54 0.00
topas命令
#topas -W
Topas Monitor for host: aix61haos1 Interval: 2 Tue Apr 7 15:19:32 2009
WLM-Class (Active) CPU% Mem% Blk-I/O%
ftp 7 0 0
System 3 50 0
Default 0 6 0
Unmanaged 0 45 0
Shared 0 3 0
Unclassified 0 28 0
svmon命令
#svmon -W ftp
======================================================================
Superclass Inuse Pin Pgsp Virtual
ftp 434 4 0 262
PageSize Inuse Pin Pgsp Virtual
s 4 KB 434 4 0 262
m 64 KB 0 0 0 0
以上说明cpu,内存使用率已经限定在指定范围内.
2.1.1.2 安装使用WLM充分发挥pSeries服务器的能力
只有AIX系统中提供的WLM（work load manager）是最完美的解决方案并可完全满足以上对系统资源调度策略的所有要求。WLM可以通过share和limit的设置，实现计算应用充分利用事务性应用变化的闲置资源，而又丝毫不影响事务性应用的运行。下面是一个设置实例。
首先建立class，本例中一个class是oracle，代表事务性应用，另一个是batch，代表计算应用。修改文件/etc/wlm/standard/rules为：
* class resvd user group application type tag
system - root - - - -
oracle - oracle - - - -
batch - batch - - - -
default - - - - - -
然后修改/etc/wlm/standard/limits文件：
system:
memory = 1%-100%;100%
batch:
CPU = 1%-10%;100%
oracle
CPU = 1%-90%;100%
再修改/etc/wlm/standard/shares：
batch:
CPU = 1
oracle:
CPU = 9
设置并启动WLM后，系统即可根据调度策略自动分配资源，无需人工干预。（当然如需要的话也可随时修改。）无论事务性应用的用户还是计算应用的用户均不会觉察到对方的存在，而系统资源的利用率则可趋于100%。
但还有一个安全问题没有完全解决。通常管理人员不希望有许多用户登录到运行着重要事务性应用的主机上来运行自己的程序。我们可以借助于IBM的Load Leveler来实现这一目标，设置一台小型系统作为计算用户的登录/调试/任务提交机，Load Leveler将自动将用户所提交的所有作业排成一个或多个队列，在主系统上在WLM的安排下与事务性应用同机运行，计算用户将永远没有机会直接登录进主系统，也不必关心自己的作业是如何完成的，只需经过一段时间后检查返回的计算结果即可。同时用户还可获得如断点设置和重启动等功能。
完整的系统框架见下图。
使用以上方案，用户即可充分利用手中的资源，又可保证系统的安全。