Implementing WCM caching using Advanced Cache

Advanced cache can be used when the WCM contents are not static. Advanced caching should be configured in "WCMConfigService.properties". The advanced cache configuration defined in the configuration file can be overridden by cache parameters defined in connect tags and URL parameters.
This will enable custom cache settings for specific pages or components. Below are the types of advanced caching types.

Site caching

Site caching is same as basic cache.

Session caching

The web page is stored in session when a user visits the page. This page will be rendered from the session cache until the user starts a new session or until the web page is expired from the cache.

User cache

The web page is stored in user cache when the user visits the page. The web page will be rendered from the user cache until it expires from the cache.

Secured caching

Secured cache can be configured to enable different user access to different web pages or components based on the user groups.

Personalized caching

The cache can be configured to cache the web pages for the users who have same personalization profile. 

Implementing WCM caching using Servlet Cache

WCM performance can be improved drastically by enabling and configuring Servlet Cache in WCM. Servlet caching can be configured for WCM connect servlet and WCM Local rendering portlet.

• Enabling caching for WCM connect servlet.
• Enabling caching for WCM Local Rendering Portlet.

Implementing WCM caching using Basic Cache

Basic cache is similar to pre-rendering. The difference is, pre-rendering will cache the site as a whole and basic cache will cache the page when it is first rendered. The subsequent access to the page will be served from the cache until the content expires from the cache. This can be implemented for static content which does not require real-time access. This can be implemented if all the contents are static. Following properties needs to be modified for implementing basic cache

\wps\wcm\shared\app\config\wcmservices\WCMConfigService.properties

connect.businesslogic.defaultcache = true

connect.moduleconfig.ajpe.contentcache.defaultcontentcache = N.A. 

Implementing WCM caching using Pre-Rendering technique

One of the simplest ways of caching WCM content is using Pre-Rendering. Snap shot of the site will be taken while pre-rendering. The site can be pre-rendered in WCM or any other web server depending upon the requirement. The contents can be viewed from WCM or web server. As the whole site is pre-rendered, the response will be extremely fast. The cacher module is used to pre-render the site.

Automatically running cacher module

The cacher module can be configured to run automatically by defining a property in WCMConfigService.properties file.

connect.businesslogic.module.cacher.autoload=true

Manually running the cacher module

Cacher module can be run manually using the URL interface. Below is an example of the URL to cache a site.

http://<host_name>:<port_number>/wps/wcm/connect?MOD=Cacher&Site=siteName&SRV=siteToBeCached&library=library_name

Following are the possible values of SRV parameter.

Service	Required Parameters	Optional Parameters
SRV=siteToBeCached The specified site will be pre-rendered with a delay mentioned in DELAY parameter	SITE = siteName Site name	DELAY  Delay in seconds LIBRARY Library name of the site. If the library parameter is not mentioned, the default library specified in the WCMConfigService.properties will be used.
SRV=flushSiteCache The pre-rendered data for site is deleted	SITE Site name	LIBRARY Library name of the site. If the library parameter is not mentioned, the default library specified in the WCMConfigService.properties will be used.

A page in the site also can be pre-rendered using the URL interface. Below is an example of the URL to cache a specific page.

http://localhost:port/wps/wcm/connect/library_name/site_name/site_area_name/content?MOD=Cacher

When SRV parameter is not specified in the URL, the page specified in the URL will be cached by the cacher module. Below is an example URL to delete a specific page from the pre-rendered site.

http://localhost:port/wps/wcm/connect/library_name/site_name/site_area_name/content?MOD=Cacher&SRV=flushPageCache

Limitations

There are some limitations of using pre-rendering technique like.

• Pre-rendering can be implemented only when the content is rendered using Remote Rendering Portlet.
• Characters that are considered as invalid in file name (depending on the operating system of the pre-rendered site) can not be used in the name field of Site, Site Areas and Content items.
• The path of the content item (e.g. site/sitearea/content) can not exceed operating system’s maximum path length (255 characters for Windows and 1024 characters for Linux)
• JSP components can not be pre-rendered.
• Can not grant access for different users in a pre-rendered site. The access is granted for the entire site based on the following property defined in WCMConfigService.properties file.

connect.moduleconfig.cacher.rendereruser = username

Implementing WCM caching using Advanced Cache

Advanced cache can be used when the WCM contents are not static. Advanced caching should be configured in "WCMConfigService.properties". The advanced cache configuration defined in the configuration file can be overridden by cache parameters defined in connect tags and URL parameters.
This will enable custom cache settings for specific pages or components. Below are the types of advanced caching types.

Site caching

Site caching is same as basic cache.

Session caching

The web page is stored in session when a user visits the page. This page will be rendered from the session cache until the user starts a new session or until the web page is expired from the cache.

User cache

The web page is stored in user cache when the user visits the page. The web page will be rendered from the user cache until it expires from the cache.

Secured caching

Secured cache can be configured to enable different user access to different web pages or components based on the user groups.

Personalized caching

The cache can be configured to cache the web pages for the users who have same personalization profile. 

Performance evaluation of Portal Servers

A common difficulty faced during execution of portal projects has been in the technical justification of the choice portal product. The observation has been that in most cases, the business requirements could be met by all of the leading products in the industry. This is exacerbated in the case of portal implementations using Java Technology, as almost all products confirm to industry standards and can be used in combination with any other Application server or Web server. In order to address this issue, a performance test of the leading industry products needs to be conducted.

The purpose of this exercise is to address the parameters and the environment for such a performance test. It also provides future directions as to how the set up can be extended.

The main benefits from this exercise would be:

• Provides a basis for suggesting hardware architecture for portal implementations.
• Provides a basis for comparison between various portal servers, although with some caveats.
• The test set up could serve as a training ground for further expansion and knowledge gain.
• Provide design inputs for portal applications based on the results.

Issues not addressed
The exercise is not intended to address the following concerns, though this could be extended to address these later:

• Performance testing of the different portal servers across different environments. It is a known issue that some portal servers work better in specific environments. However the objective here would be to evaluate all the portal servers on standard minimum environment.
• Performance testing scenarios with clustered environments at various levels or multiple CPUs per server. The primary motive not to do this would be cost and set up effort involved.
• End-to-End performance testing including application server, database server, directory server etc. These factors would induce additional complexity leading to a focus loss for the entire exercise.
• Trying to provide industry standard bench marking figures. By not addressing the points mentioned above, it would not be possible to claim the results of the performance test as an industry-wide benchmark.

The following table gives a brief description of the various factors that need to be measured.

Factor	Description
Transaction Time	The time required to complete one complete transaction by the server
Errors rate	The number of errors generated at the server per second
Processor Utilization	The percentage of processor time used by the process
Response Time	The time taken by the server to respond to the request, including the network delays
Memory Usage	The memory usage pattern

These factors need to be measured against varying values of the following base factors:

Factor	Description
No of Tabs to be loaded	The number of tabs to be loaded for the user
No of users	The total number of users simulated by the test
No of user groups	The number of user groups
No of user roles	The user roles
No of portlets/tab displayed to the user	The number of portlets to be displayed to the user

The following factors would remain constant for all the tests. 

Factor	Description
Type of Portlets	Whether the portlets are Local or Remote. If local, are the portlets based on XML, JSP or URL scraping
Hardware Configuration	The hardware configuration of the server
Logging Level	The logging level in the web server
Think Time	The think time configuration
Keying Delay Time	The Keying delay time configuration
Client Machine configuration	The configuration of the machine which hosts the browser.
Authentication mechanism	The authentication mechanism for the portal application

How to improve Portal Page Rendering Performance?

When you install WebSphere Portal, you always have noticed that when you login to the server very first time, it takes some extra loading time for each JSP page. That extra load time is because of the fact that each JSP page on server must be compiled first time its is accessed, so in order to improve load time you can make use of precompile-jsp command.

1. From the command prompt, navigate to this directory

wp_profile\ConfigEngine (For WPS 6.x.x)
wp_profile\bin (WPS 7.x)

2. Run the following command

ConfigEngine.bat precompile-jsp –DWasUser=USER – DWasPassword=PASS 

Enabling developer's mode in IBM WebSphere Portal 7

One of the mistakes that developers do while working with WebSphere Portal Server is they don't use the Developer Mode for their development purpose. The result is low productivity because most of the time is consumed in starting and stopping the portal server. When portlet application is developed on your local box it is very annoying to wait for server start up taking 15 to 20 minutes. The portal server start up time can be reduced to half when you enable developer mode in WebSphere portal 7. Like version 6, IBM WPS version 7 also facilitates a developer to start the server in a Developer mode.

This is one of the best tweaks that I like to apply on my DEV environment when working on WebSphere Portal Server especially when the hardware resources are limited.

This setting will disable non-essential applications from getting started when the server starts. In case any one of these applications are required after the server has started, WebSphere will lazy load the application. From the end users view this means that the first time someone tries to render a portlet they could receive a portlet unavailable message. In the background the application will be started and the next time the user renders the portlet the application will be available. Without a lot of custom applications, enabling developer mode can improve the startup time by about 50%.

Here are the steps to enable developer mode:

1. Stop the server
2. Go to <portalserver_root>\wp_profile\ConfigEngine
3. Execute the following command

   ConfigEngine.bat enable-develop-mode-startup-performance

4. Start the server

Steps to disable Developer Mode

1. Stop the server
2. Go to <portalserver_root>\wp_profile\ConfigEngine
3. Execute the following command

   ConfigEngine.bat disable-develop-mode-startup-performance

4. Start the server.


You can see the clearly see the difference in server startup performance now.

Configuring developer mode in WebspShere Portal Server 8.0

This article explains how to configure and un-configure the development mode option.  

Developer mode is for a development environment only and should not be used in a production environment

The JVM will be switched to development mode and the initial heap size will be set to the maximum allowable heap size to reduce the amount of garbage collection during start up.

Portlets and Web Applications will be activated on first access and not at the start up. Since some of the portlets and applications are required at start up, a white list, which contains the list of applications, will hold the applications still started at start up.

Note: To add applications to the white list, modify the wp_profile_root\PortalServer\config\StartupPerformance\wp.base_TargetMapExclList.properties file. Add a line such as App_name, where App_name is the name of the application. Log on to the WebSphere Integrated Solutions Console and go to Applications -> Application Types ->WebSphere enterprise applications to get a list of available applications.

 WebSphere portal server initially will have 93 applications installed. Those applications are

1 PA_MosoftExchange2010
2 wci
3 wcm
4 PA_Community_Port_App
5 PA_FS_Disambiguation
6 PA_Markups_Manager
7 Default_Theme_80
8 Dojo_Resources
9 wps
10 PA_DynamicUIApp
11 PA_WPF
12 PA_PropertiesPortApp
13 PA_MPagesandFavorites
14 PA_portletWiring
15 PA_WPS_Welcome
16 IEHS_war
17 PA_WCMLRingPortJSR286
18 lwp_peoplefinder_war
19 PA_Portlet_Manager
20 EphoxEditLive
21 PA_Blurb_1
22 PA_Properties
23 WCM_EXTENSION
24 PA_Web
25 PA_Manage_Webservices
26 PA_Clients_Manager
27 WebResourceServlet.ear
28 PA_FrequentUsers
29 PageBuilder2_Theme
30 PA_PTransformationApp
31 Personalization_Workspace
32 PA_Search_Center
33 PA_ThemesAndSkinsMgr
34 PA_ResourceView
35 JavaContentRepository
36 PA_Principals_Manager
37 wps_theme
38 PA_UniqueNames
39 PA_WebDockPortServlet
40 PA_Import_XML
41 SpellChecker
42 Seedlist_Servlet
43 pznscheduler
44 PA_Set_Permissions
45 PA_wp.vwat.manager
46 PA_PortalWSRPProxy
47 WSPolicyManager
48 PA_SearchSitemapPort
49 PA_Pingpageproperties
50 PA_WCM_Admin
51 PA_BksFinalJSRProject
52 PA_Impersonation
53 PA_Eecontentandlayout
54 PA_WebScanner
55 Quickr_Document_Picker
56 PA_MageVirtualPortals
57 PA_ParamConfig
58 PA_Tag_Cloud
59 PA_Banner_Ad
60 MashupCommonComponent
61 PA_Roles
62 PA_Policy_Status
63 Live_Object_Framework
64 PA_Settings
65 Theme_Modules
66 PA_Feed_Service_Admin
67 PA_IWidget_Wrapper
68 UserProfileRESTServlet
69 PA_Tracing
70 PA_spa
71 PA_Login_Portlet_App
72 lwp_peoplePicker_war
73 PA_wp.feedspace
74 wp.vwat.servlet.ear
75 lwp_groupsViewer_war
76 pznpublish
77 lwp.addtosametimelist_war
78 PA_Blurb
79 PZN_Utilities
80 PA_ContactList
81 PA_appearance
82 PA_Credential_Admin
83 wps_scheduler
84 eventExplorer
85 Personalization_Lists
86 PA_CredVaultDialog
87 feedReader
88 AJAX Proxy Configuration
89 PSESearchAdapter
90 PA_WCM_Authoring_UI
91 PA_URL_mapping
92 websiteDisplayer
93 PA_Selfcare_Port_App

Run the ConfigEngine.bat enable-develop-mode-startup-performance -DWasPassword=password task, from the wp_profile_root\ConfigEngine directory, immediately after installing WebSphere Portal to develop portals and portlets. Then stop and restart the WebSphere_Portal server to propagate the changes.

1 PA_MosoftExchange2010
2 wci Application is in exclude list. Skip ...
3 wcm Application is in exclude list. Skip ...
4 PA_Community_Port_App
5 PA_FS_Disambiguation
6 PA_Markups_Manager
7 Default_Theme_80 Application is in exclude list. Skip ...
8 Dojo_Resources Application is in exclude list. Skip ...
9 wps Application is in exclude list. Skip ...
10 PA_DynamicUIApp
11 PA_WPF
12 PA_PropertiesPortApp
13 PA_MPagesandFavorites
14 PA_portletWiring
15 PA_WPS_Welcome
16 IEHS_war Application is in exclude list. Skip ...
17 PA_WCMLRingPortJSR286 Application is in exclude list. Skip ...
18 lwp_peoplefinder_war Application is in exclude list. Skip ...
19 PA_Portlet_Manager
20 EphoxEditLive Application is in exclude list. Skip ...
21 PA_Blurb_1
22 PA_Properties
23 WCM_EXTENSION
24 PA_Web
25 PA_Manage_Webservices
26 PA_Clients_Manager
27 WebResourceServlet.ear
28 PA_FrequentUsers
29 PageBuilder2_Theme Application is in exclude list. Skip ...
30 PA_PTransformationApp
31 Personalization_Workspace Application is in exclude list. Skip ...
32 PA_Search_Center
33 PA_ThemesAndSkinsMgr
34 PA_ResourceView
35 JavaContentRepository Application is in exclude list. Skip ... 36 PA_Principals_Manager
37 wps_theme Application is in exclude list. Skip ...
38 PA_UniqueNames
39 PA_WebDockPortServlet
40 PA_Import_XML
41 SpellChecker Application is in exclude list. Skip ...
42 Seedlist_Servlet Application is in exclude list. Skip ...
43 pznscheduler
44 PA_Set_Permissions
45 PA_wp.vwat.manager
46 PA_PortalWSRPProxy
47 WSPolicyManager
48 PA_SearchSitemapPort
49 PA_Pingpageproperties Application is in exclude list. Skip ...
50 PA_WCM_Admin
51 PA_BksFinalJSRProject
52 PA_Impersonation Application is in exclude list. Skip ...
53 PA_Eecontentandlayout
54 PA_WebScanner Application is in exclude list. Skip ...
55 Quickr_Document_Picker Application is in exclude list. Skip ...
56 PA_MageVirtualPortals
57 PA_ParamConfig
58 PA_Tag_Cloud
59 PA_Banner_Ad
60 MashupCommonComponent Application is in exclude list. Skip ...
61 PA_Roles
62 PA_Policy_Status
63 Live_Object_Framework Application is in exclude list. Skip ...
64 PA_Settings
65 Theme_Modules Application is in exclude list. Skip ...
66 PA_Feed_Service_Admin
67 PA_IWidget_Wrapper
68 UserProfileRESTServlet Application is in exclude list. Skip ...
69 PA_Tracing
70 PA_spa
71 PA_Login_Portlet_App Application is in exclude list. Skip ...
72 lwp_peoplePicker_war
73 PA_wp.feedspace
74 wp.vwat.servlet.ear
75 lwp_groupsViewer_war
76 pznpublish
77 lwp.addtosametimelist_war
78 PA_Blurb
79 PZN_Utilities
80 PA_ContactList
81 PA_appearance
82 PA_Credential_Admin
83 wps_scheduler Application is in exclude list. Skip ...
84 eventExplorer Application is in exclude list. Skip ...
85 Personalization_Lists Application is in exclude list. Skip ...
86 PA_CredVaultDialog
87 feedReader Application is in exclude list. Skip ...
88 AJAX Proxy Configuration Application is in exclude list. Skip ...
89 PSESearchAdapter
90 PA_WCM_Authoring_UI Application is in exclude list. Skip ...
91 PA_URL_mapping
92 websiteDisplayer Application is in exclude list. Skip ...
93 PA_Selfcare_Port_App Application is in exclude list. Skip ...

Run the ConfigEngine.bat disable-develop-mode-startup-performance -DWasPassword=password task, from the wp_profile_root\ConfigEngine directory, to revert back to a production server. Then stop and restart the WebSphere_Portal server to propagate your changes. 

Difference between Friendly URL’s and URL mappings

In this article, I am going to talk about friendly URLs, URL mappings and difference between them.

Friendly URLs

Friendly URLs are human readable URL prefixes generated based on the content node hierarchy. The URL prefix for content sub node will contain the prefix assigned to the super and all other nodes above it. Friendly URLs are added to a page through page properties in Admin UI or we can add them through XML access too.



By default, Friendly URLs are disabled in websphere portal, to enable them

1. Open WAS admin console.
2. Navigate to Resources -> Resource environment -> Resource environment providers.
3. Search WP_ConfigService and click custom properties.
4. Click “NEW” and add “friendly.enabled” in name and “true ” for the value.
5. If it already exists change “friendly.enabled” to true

The URL assigned is stored in the page level metadata as com.ibm.portal.friendly.name.

URL Mappings

URL mappings are used to define the human readable URL prefixes to the content in the portal which will serve as entry points onto the portal. However, these URL mappings will not be preserved upon navigating to other content node. We can define URL mappings through Admin UI and XML access. Portal does not provide any API to construct URL mappings programatically. URL mappings are preferred when we need a URL to link up between two different portals. This will allow us to maintain a constant URL even with change in content node.



Few Important Points

1. We need to maintain URL mappings for each entry point and they will not be valid for the next navigation state.
2. We need to define friendly URLs for all the pages or nodes in the hierarchy before assigning it to sub pages. It cannot resolve a friendly URL unless and until all pages are properly defined with respective URLs.
3. For friendly URLs, URl assigned is stored in page level metadata as com.ibm.portal.friendly.name.

What is the best way to deploy portlets within Portal environment?

This article lists down different ways of deploying portlets within Portal environment listing advantages and disadvantages of each.

Portlet Deployment

One Portlet per war

In this approach, each portlet is bundled as one war file.

Advantages:

• Abstraction to the lowest level
• Independent development and testing of portlets
• Change to single portlet will not impact other portlets within portal

Disadvantages:

• Messy deployment as the number of portlets grow
• Sharing of portlet session is an issue

All portlets in a single War file

In this approach, we pack all the portlets in one war file.

Advantages:

• Clean deployment, easy to manage
• Easy to share portlet session

Disadvantages:

• Parallel development is a challenge
• The size of the deploying war becomes extremely large and takes a long time to deploy
• Single change in one portlet will cause a redeploy of all portlets, adding re-testing overheads and making portal unavailable

Grouping portlets in one war

This approach refer to portlets grouped together based on function/ same functionality into single WAR files. 

Advantages:

• Small changes to a functionality will not affect the overall portal
• Clean and easy to manage
• Portlets which need to share session will be grouped into one
• Parallel development at functionality level is possible

Disadvantages: 

• Maintenance at individual Portlet level might affect other packaged portlet of the application

Shared library management in ext of Portal server

Shared library in ext of Portlets

Shared Libraries

Apart from portlet applications, there are certain shared libraries used by most of the portlet applications (WAR's). This lead to challenge of how to deploy these shared applications. Here are few options:

Single Portlet application and shared libraries packed into one EAR 
This approach suggests having single portlet application, along with shared libraries and resource files, packed as one EAR file.

Advantages:

• Each EAR will be truly independent
• Common functionality could be extended based on the need of the portlet application
• Changes to shared libraries will not impact all the other independent EAR's

Disadvantages: 

• Each EAR would be large and will take longer deployment time
• Each individual EAR would contain copy of the framework classes and maintainability of different versions of framework classes in different columns will be a challenge
• More complex deployment process
• Changes to shared libraries will require redeployment of all the EARs
• Complex deployment
• Class loading strategy of the application server would have to be restricted to PARENT LAST

Multiple Portlet applications and shared libraries packed into one EAR file 

This approach suggests that multiple portlet applications along with shared libraries and resources files, such as properties, packed into one single EAR.

Advantages:

• All portlet applications share same common libraries

Disadvantages:

• Big size and will take a long time for deployment
• Change to single portlet application will require redeployment of whole EAR and thus unavailability of the application
• Complex deployment

Shared library in ext of Portal server

This approach suggests that the shared library to be placed within the ext library directory of the portal server. This approach is suggested when there is are framework libraries which need to be shared across the organization (Organization level frameworks for logging/exception handling etc.) and each application hosted in the environment should follow those standards.

Advantages:

• One of the most common way of sharing the files among the multiple applications
• In portal world, all the common files pertaining to theme, portlets and third party application are stored in shared library
• No need to use Dyna Cache or JSR 286 events to  save and share values across portlets
• Library would be available across applications
• Individual applications would be lighter since they won’t contain the code for framework classes

Disadvantages:

• Change management for the shared libraries would be very risky

Steps for Creating a Shared library on Portal Server

• Logon to Websphere Application server console
• Navigate to Environment -> Shared Libraries
• Click apply and save it

Assigning to a server 

• Go to servers -> Application servers -> websphere portal -> Java and Process management -> classloader.
• Click Shared library references
• Add the library that you want to share
• Save the configuration and restart the Portal server.

Note: Restart of server is mandatory for the class loader to load all the newly added class files. Now, you can add the shared jars to build path for proper compilation and deployment.