Luke Cressman
Lab Product Specialist,
Personalization
1.
Before
you Start
- Read the Personalization
section of the Information
Center
- Apply the latest fixpack
version and ifixes
- Turn on Portal
Security
- Don't create anything
under wpsadmin
- If you plan to
publish/export Personalization Artifacts to another server the LDAP
servers used should match.
- Develop Rules on a
"Development" server
- Same server that WCM
Content
is authored on if integrating
- Never create/edit rules
in production (everything is live)
2.
Rule
Design Methodologies
If the only attributes you want to personalize on are
Authoring Templates, Site Areas, Categories and Keywords, Menu Components are
the best option in terms of performance. For any of the above that are chosen
for the Menu Element Query only content that match all the search search
criteria will be returned (only AND condition between search criteria).
Categories does allow for partial matching of its search criteria.
·
Heavy profiler that map to
static queries using Bindings
If you have a set number of profiles that all users will
fall into, this scenario can have a finite set of queries that run against the
DB,
make very good use of cache, and therefore perform very well.
·
Dynamic Select
Actions
If there are too many profiles to define or user based
attributes that drive what content should be returned, then creating dynamic
select actions should fit this scenario. Be careful not to create a rule that
will be so dynamic that it generates a different query for each user that
executes the rule.
·
Visibility
If you have certain pages/portlets that should be
shown/hidden to certain users, then visibility rules should be your preferred
use.
o
With Parallel Portlet Rendering
enabled, the portlet is executed before the visibility rule. The function of
hiding/showing the portlet is the same, but the server will have to process the
portlet code first. It is not recommended to use PPR in conjunction with
visibility rules on “heavy” portlets.
o
You can use Portal User, Date,
any Application objects which implement the SelfInitializingApplicationObject
interface (see JavaDoc), almost anything you can use in other rules
o
The exception is Session and
Request
information, which is NOT available in rules used in Attribute Based Admin(not
without some help)
3.
Authoring
·
Use "Select View" in
the upper right side of the Personalization Navigator to only display the types
of items you're looking for
·
Keep Select Action rules as
simple as possible for the level of personalization required - minimize the
number of conditions in each rule. These generate queries when executed, so
the more complex the rule, the longer the query time on the database.
·
When selecting individual items,
select by uuid is faster than path/name
·
Querying for Authoring Template
properties is more expensive - reduce the number of these conditions if
possible.
·
If using conditions based on
Authoring Template properties, you should first specify a condition for
Authoring Template and choose the template from the picker.
·
When querying by category,
location, or site area, use the “is exactly” operator as it is the fastest.
This may require some planning on the WCM content development side to make sure
the rules don’t have to search sub-folders for content.
·
Extending Resources
o
See:
http://www.ibm.com/developerworks/websphere/library/techarticles/0702_brunn/0702
_brunn.html
o
ID translation
RegularExpressionSecurityTranslator
Configured in PersonalizationService.properties
translator.pattern=^.*(?:uid|UID|cn|CN)=([^,]+).*$
translator.replacementPattern=$1
The default pattern of and replacement pattern
change
… uid=wpsadmin, ...
… cn=wpsadmin, ...
Into
wpsadmin
Works for many common LDAP installations. May require some
minor changes for other installations or producing other output.
Custom translator classes are still possible as well if the
portal DN doesn't include the needed translated ID.
o
Javadoc
Installed under
<wps>/doc/Javadoc/Personalization
4.
Caching
Personalization caches the
parsed rule XML and campaigns, the results of select actions, and user objects.
Caching occurs in two areas. Personalization first caches its lookups for
internal objects (rules, campaigns, rule mappings and resource collections),
known as internal cache. Secondly, Personalization also caches the results of
calls to findById or findResourcesByQuery on a resource domain
implementation. The resource domain is one of the classes that implements a
resource collection. findById and findResourcesByQuery are the
two methods Personalization uses to find data in your data sources. By caching
the results of these two methods, Personalization caches resources returned by
resource collections, known as the results cache Both caches use the WebSphere
Dynacache.
·
Cache configuration is defined in
the PersonalizationService.properties file located in
(v6.0)<portal_root>/shared/app/config/services or (v6.1) <wp_profile>/PortalServer/config/config/services.
·
For a preferred set of cache
settings to start with, use this file: Pers
onalizationService.properties
·
Caching is “per-query” not
“per-rule” or “per-user”
Select
content where content.category is user.favoriteCategory
Cache
key is “category = ‘sports’”
Many
users may have the same favorite category, and will share a cache
entry
·
Consider increasing the length of
the cache timeout if content doesn't change rapidly to prevent periodic
slowdowns when the cache clears.
·
WCM Cache
·
See:
http://www.ibm.com/developerworks/websphere/library/techarticles/0701_devos/0701
_devos.html
·
Note that the
"Personalized" setting has nothing to do with PZN results
5.
Performance
It is often asked, “How many
rules can I have per page?” or “How much personalization can I use?” These are
not at all simple questions. The answers to these questions about performance
depend not only on the number of rules on each page, but also on the character
of those rules. It isn’t sufficient to say the rules themselves should be
“simple” and only have a few conditions to ensure proper performance.
As shown in section 2 of
this document, the level at which a site is personalized can take on many forms
based on the design paradigm.
Sites
can use personalization in multiple places on the same page. Obviously, as the
number of rules per page increase, so will response times and required
resources. In this case, generally not every piece of content is
personalized. Even if all content results from rules, caching can be effective
in reducing response times.
Sites
can have pages utilizing a single rule which shows vastly different content for
each user. In this case the dynamic query generated by each user is used to
return the content. As shown in section 5, Personalization caches the content
returned to each page by the query used to retrieve them. If multiple users
generate the same query when executing a rule, they will share the cached
content. If each user generates a unique query, then sharing of cached content
will be impossible and performance will suffer.
The ability for each page to
perform depends on the cache utilization. This utilization depends on the
number of query permutations the set of site users can generate from each rule
running on the page. Lets assume a rule is based on the combination of the
following attributes: city, state, region, division, department, store
number. The number of permutations of this query isn’t as simple as the
product of the number of possible values for each property since some
properties imply others. Its also true that since the value of some properties
imply the value of others, their inclusion in the rule is redundant and can
only complicate the end resulting query. Knowledge of your user population and
data or content is critical
Below are some general guidelines to start, but each personalized page should
be tested under a projected load to make sure response times are
acceptable.
- Limit the number of
content spots per page to 4.
- Limit the number of total
rules run per page
·
Think about the
number of rules referenced in the case of Bindings and Profilers
- Personalizing based on
properties directly on Web Content will be faster than personalizing based
on properties of an Authoring Template. Limit the number of times
properties from Authoring Templates are used in rules.
- Personalization Components
perform better than JSP Components.
- Application Object code is
invoked during rule execution - make this as fast as possible.
Application Object init speed should be taken into account in deciding
whether to store on the request or session. Do as much as possible in the
init methods to prevent work being done multiple times in the get
methods.
- If you are not using email
campaigns or rule events, disable pznscheduler.ear.
- If you are not using the
Likeminds Recommendation Engine, disable pznutilities.ear.
- If you are not utilizing
links in WCM, set rulesEngine.bypassWebContentLink=true in
PersonalizationService.properties
- Ensure that all referenced
user attributes are set in the Puma service to be loaded at user login.
See:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.
ent.doc/wpf/tune_other.html
6.
Troubleshooting
·
Logs and tracing
o
Follow the Mustgather documents
for logging and tracing
Mustgather: Personalization 6.0
http://www-01.ibm.com/support/docview.wss?uid=swg21245725
Mustgather: Personalization 6.1
http://www-01.ibm.com/support/docview.wss?uid=swg21315586
o
Install PK77497. This APAR
allows PZN to use the dynamic trace setting in Portal rather than the traces
having to be set in WAS and the Portal restarted.
·
Known issues.
o
Publish/Import
The database exception shows duplicate data in the Portal
Access Control (PAC) tables:
DataStoreCont E com.ibm.wps.datastore.impl.DataStoreContext
handleException EJPDB0099E: Error occurred during database access. Last SQL
statement is [INSERT INTO...
com.ibm.wps.util.DataBackendException: EJPDB0099E: Error
occurred during database access. Last SQL statement is [INSERT INTO
...
com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE:
-803, SQLSTATE: 23505, SQLERRMC: 6;CMJCR01.PROT_RES
There are occasional scenarios where the Poratal Access
Control (PAC) data is not completely removed from the database when content is
removed from either WCM or Personalization.
When this occurs to the point of stopping current function,
this data needs to be cleaned up with the following SQL statement:
DELETE FROM <schema>.PROT_RES WHERE RES_TYPE IN (7003,
46, 51, 49, 48, 52) AND EXTERNAL_UID NOT IN (SELECT UUID FROM
<schema>.ICMSTJCRWSNODES)
Afterward, please restart Portal server and re-attempt the
import.
o
Custom User Collections
When using LDAP or custom resource collections, the #1 issue
is that the WAS security context ID doesn’t match the ID expected by the
collection.
Look for “When looking for the ‘<attrName>’ attribute,
Personalization could not find a user object from the collection
‘<collectionName>’ with the user id ‘<userId>’ during the
processing of rule ‘<ruleName>’.
Search log for “getTranslatedUsername”
Example trace file entry:
com.ibm.websphere.personalization.context.PersonalizationCont
ext
getTranslatedUsername Servlet.Engine.Transports : 0
EXIT "uid=<username>,o=default organization“
This tells you what user id Personalization will try to look
up the user with
In this case, Personalization will try to look up the user
as
"uid=wpsadmin,o=default organization“
Maybe I really should be using a translator to translate
that to simply “wpsadmin“ ?
7.
References
Portal
6 Infocenter: Personalizing
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.
ent.doc/wpf/cm_intr.html
Portal
6.1 Infocenter: Personalizing your content
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp?topic=/com.ibm.w
p.ent.doc/pzn/pzn_intro.html
WCM 6.1
Infocenter: Personalizing your content
http://publib.boulder.ibm.com/infocenter/wcmdoc/v6r0/index.jsp?topic=/com.ibm.lo
tus.wcm.doc/pzn/pzn_intro.html
Extending
WebSphere Portal V6 personalization capabilities
http://www.ibm.com/developerworks/websphere/library/techarticles/0702_brunn/0702
_brunn.html
Exploiting
personalization in WebSphere Portal V6.0
http://www.ibm.com/developerworks/websphere/library/techarticles/0610_schoeffing
/0610_schoeffing.html
Best
practices for using IBM Workplace Web Content Management V6
http://www.ibm.com/developerworks/websphere/library/techarticles/0701_devos/0701
_devos.html
Portal
Tuning Guide
http://www-01.ibm.com/support/docview.wss?rs=688&uid=swg27008511
Extended
Cache Monitor
http://www.ibm.com/developerworks/websphere/downloads/cache_monitor.html?S_TACT=
105AGX10&S_CMP=ART
IBM
WebSphere
Portal: Performance testing and analysis
http://www.ibm.com/developerworks/websphere/library/techarticles/0807_lang/0807_
lang.html
This is a
living document and may change frequently based on new information.