Portal administration and performance

From a J2EE perspective WebSphere Portal consists of various ear and war files, datasources, and configurations. The main application is the wps.ear file. It holds the main Servlet, XMLAccess, the contenthandler and poc Servlets and WSRP functionality. Whenever a server side page switch happens the main Servlet is invoked. The default URLs of the Servlet are /wps/portal and /wps/myportal.
WCM's main components are the wcm.ear file and the rendering portlet. The wcm.ear file contains the Content servlet that is accessed via the default URL /wps/wcm.

Any page accessed is aggregated by including the theme, skins, portlets, widgets and other components on the page.  In case the WCM portlet is on the page it will call the WCM APIs to retrieve the data from caches or the Java Content Repository component.
The rendered data is then returned to the browser that interprets the markup. The browser will request resources linked from the markup or javascript - those are typically static resources like CSS Stylesheets or Pictures or Javascript files. The requested static resources could come from the theme or from portlets or from the WCM servlet (or other sites or custom applications).
Alongside the request a session cookie is sent along to the browser and it will be submitted on subsequent requests - identifying the session.
In case the user is authenticated the Single Sign On cookie is sent to the browser and  will be submitted on subsequent requests - identifying the user.
When the user logs out all sessions associated with the session cookie will be invalidated.
It is important to understand that the session identifier (in most cases the cookie) only is a link to map the request to all the sessions of the different ear files on the server.

Session size:
Sessions effect the performance of the system by using up memory and being kept in the memory until they expire or when they are terminated (e.g. at the time of user logout). The size used up by the session depends on which objects your custom code stores inside the session and how long the objects are held. The session size limits the amount of concurrent users on the system based on the configured heap size and the available free memory. While Session size is much less of an issue with 64 bit JVMs than with 32 bit JVM, session size should at least be understood. For example, large sessions take longer to garbage collect regardless of the JVM size.
 
Session Scope:
Each ear/war file deployed has its own HTTP session. Multiple Portlets that are part of the same ear/war file will share the same session. Note that this is NOT the main session used by the wps.war but rather a new session created especially for all porlets running in this ear/war. Session sharing across ear files is currently not possible. The Business Level Applications functionality is not supported with Portal/Portlet applications.
The session configuration for the ear files can either be administered at the server level or individual  ear file level. Our recommendation is to configure the session globally at the server level.
 
Public sessions:
By default WebSphere Portal does not create a session for the public (e.g. anonymous user) area, but only when the user authenticates to the protected area of Portal. This behavior is controlled by the setting public.session in WP NavigatorService.
 
Session Timeout:
The session configuration also includes the session timeout. The session timeout is relative to user interaction - if e.g. the user is inactive for 40 minutes and the session timeout is 30 minutes, the sessions will be invalidated.
By default, in case of a session timeout, WebSphere Portal will log the user out and redirect the user to the session timeout page. This behavior can be controlled by the setting timeout.resume.session in the WP ConfigService.
Given that WebSphere Portal and Web Content Management consist of multiple ear files that have separate sessions, these sessions can "time-out" independent of each other. This can have unfortunate side effects. We recommend to code the portlets and theme components to be able to handle this case. To avoid this issue it is possible to configure the sessions of the portlets and themes to never time out. This is acceptable since when the main Portal (wps.ear) session times out or the user logs out, Portal invalidates the sessions of all portlets and themes and other components associated with the session identifier (typically the session cookie).
 
Session Identification:
Besides the session cookie approach it is also possible to configure SSL session tracking or URL rewriting. Our recommendation is to use the identification of the session via the cookie.
By default the name of the cookie is JSESSIONID. In case you are accessing other WebSphere applications (besides Portal) that use the same cookie name (at the same cookie domain) you can lose your session(s).
There are a few options to solve this issue:
- Ensure different cookie domains are used
- Rename the session cookie in the other application
- Rename the cookie in Portal - note that besides renaming the cookie in the WebSphere Application Server Session configuration section you also need to set the custom property cookie.sessionid.name in WP ConfigService
- Configure to reuse the session cookie supplied by the other application - this can have several disadvantages as then two applications will effect each other when changing the cookie
 
Session  Affinity:
In a cluster the web server Plugin routes the request to the configured WebSphere Application Server JVMs based on the round robin or random algorithm. This only holds true though for requests without a session. Requests that already have a session identifier (e.g. JSESSIONID cookie) present will be routed based on the configured cookie. In a cluster the cookie value holds the JVM identifier at the end. In this way the Plugin routes the requests to the correct Application Server JVM in the cluster.
If the server is unavailable the Plugin marks the Application Server as down and will send the request to the next Application Server JVM in the list. If Session Failover was configured the other Application Server JVM will be able to access the session that was created on the other Application Server JVM. See Session Failover for details.
 
Session Failover:
In critical applications it can make sense to configure session persistence to be able to restore a session on a different JVM than where it was originated. Note that this has a significant performance impact. In most cases this feature is not required. Different possible options for session failover exist - persisting the sessions in a database, memory to memory replication or storing the sessions in WebSphere eXtreme Scale. 
 
Session Security:
For authenticated users the Single Sign On token identifies the user while the session cookie identifies the session and so the data of the user.
WebSphere Application Server has the feature "Session Security Integration" that will only allow access to the session for the user that created the session. While this feature can prevent session spoofing, it can have some performance / functional impacts. It is disabled by default.