Administer > Manage WebSphere Commerce features > WebSphere Commerce integration with WebSphere Portal
Plan the WebSphere Commerce Portal site
There are a number of portal page layout design considerations when planning the WebSphere Commerce Portal site. These considerations include using volume of user traffic as the primary driving factor, performing updates in action phase only, and avoiding the following practices: too many portlets on a single page, overloaded themes, unnecessary portlet wires, large JavaScript, unnecessary drag-and-drop operations, and improperly planned caching.
Use volume of user traffic as the primary driving factor
It is possible to categorize two main types of WebSphere Portal page layout recommendations based on user traffic:
- A single page layout providing a similar consumer direct user shopping experience through the WebSphere Portal server. This page layout is designed to demonstrate more of the technology in JSR 168, such as portlet-to-portlet communication and the use of standard portlet libraries. This design, however, may only be suitable for low to medium traffic sites, such as a Business-to-Business shopping scenario.
- In a popular site where usage traffic is relatively high, it is necessary to use a slightly different page layout to separate the user specific content which cannot be shared across the entire site, from the sharable content such as categories and various product items. This enables the best caching strategies and techniques to be used for each type of content in the WebSphere Portal environment.
In a typical low traffic express shopping site, the WebSphere Portal designer presents as much related information on the same page as possible to the end WebSphere Portal user. This is done to make the shopping flow more efficient and reduce shopping cart dropout rate. The following example shows a page layout arrangement for a low traffic site:
The WebSphere Portal user can have the catalog navigational information, product information, order information, and the user's own profile information displayed on a single page. A typical shopping flow can be completed with just a few clicks and a few page refreshes.
From a Web development point of view, the ideal WebSphere Portal web site enables content providers and administrators to provide content to site visitors without having to consider the delivery characteristics of the content. Content and applications should ideally be provided in a way where the information is automatically delivered to a site visitor in the most convenient and applicable manner. Performance and scalability considerations, however, for high volume, high performance Web sites such as consumer direct sites, make it necessary to create a distinction between static content and dynamic applications. Different caching technologies should be used for delivering static content and dynamic applications.
For example:
- Avoid serving static content by the application server:
The same information is provided to all users with static content. Static content is stored in HTML files or in a form of a binary image file on a server in many cases, which users access using Web browser clients. Although the application server can technically serve static content, doing so increases the workload on the WebSphere Portal application server and therefore reduces the overall throughput of the WebSphere Portal site. Having static content served by an external source, such as a web server, can not only reduce the additional workload on the application server, but the external source can also filter out unnecessary traffic and therefore free up network bandwidth for other relevant uses.
- Avoid mixing sharable and non-sharable content on the same page:
Dynamic content generated by MVC Portlet can be classified into two main categories: sharable content, such as catalog and product information, and non-sharable user-specific content, such as user profiles and address book information. By separating the sharable content from the non-sharable user-specific content, it is possible to make use of other caching methods available, such as full page caching.
In a typical high traffic WebSphere Portal site, all catalog browsing and its related product information can be grouped into one set of portlets to be displayed on a single shopping page, while the WebSphere Portal user's specific information, such as the shopping cart and account information, can be placed on other pages. The following example shows a page layout arrangement for a high traffic site:
Performing updates in action phase only
IBM recommends that Process and Change service requests through the MVC Portlet action are used, while Get requests should be done through render requests from the JSP getData tag. This avoids potential deadlock situations from occurring while performing a long-running action request that may cross-reference other resource dependencies generated by other portlets on the same WebSphere Portal page.
Avoiding too many portlets on a single page
The CPU time required to generate a page is greatly influenced by the number of portlets on that page, as all the portlets on the page must be re-rendered on each page view unless their output is cached. One way to reduce the CPU cost to generate a page is to remove one or more portlets from that page. Consider whether pages containing many portlets can be split into several pages, distributing its portlets across those pages. This decision can be made easier by considering whether it is necessary for users to access all the portlets on the single page, or if separating them into several pages affects their usage.
Avoiding overloaded themes
Themes and navigation bars are a set of common elements that appear on every WebSphere Portal page. Themes therefore contribute a significant portion to the overall render payload. It is important to carefully consider what to include and exclude on the theme to be used for the WebSphere Commerce Portal pages. A general guideline is simply the less content, the better, unless the caching strategy can also extend to themes. WebSphere Portal provides a default theme and skin that demonstrate the portal server's rich set of functions. If the portal site does not require all of the functionality provided by the shipped themes and skins, you can take advantage of performance benefits by selectively removing some of its functionality. See Performance guidelines for themes and skins for more information.
Avoiding unnecessary portlet wires
Wires allow portlets to communicate. They are used to save property transfers between portlets and are triggered through an action request. It is possible that a single action request can result in causing double or even more additional overhead due to the triggering of portlet wires. If portlets on a frequently accessed WebSphere Portal page in a high traffic site require the use of portlet wires, one way to reduce its side effects is to use caching.
Avoiding large JavaScript files
JavaScript must be parsed and interpreted by the client. Therefore, very large JavaScript files, for example, thousands of lines, can take a long time to be processed, even if they do not contain complex logic.
Avoiding unnecessary drag-and-drop operations
Drag-and-drop functionality can certainly improve the user experience on a WebSphere Portal site. However, the embedded <dnd> portlet tag generates a substantial amount of code which can potentially reduce application throughput. If you are planning to make use of this drag-and-drop feature, consider using an appropriate caching strategy to allow the application server to, if possible, reuse the generated code.
Cache is a planning activity
Cache is best done as a planned activity, not as something that is retrofitted into an existing application. Consider a newly developed system that is not only frustratingly slow, but also starts to break down when placed under anything approaching projected production system loads. It can become a major exercise to change the application in order to resolve the problems when this happens. Spend sufficient time analyzing the performance requirements in the early stages of development. This helps you meet the project deadline while delivering a well-performing system, not just a functioning system, and ensures that you create a Web site that satisfies the end users.
The best candidates for caching are operations that are large, slow, or resource-intensive to produce. It is important to ensure that they are publicly accessible when evaluating potential caching candidates. The more users that can take advantage of a given cache entry, the better. Do not, however, cache pages that are never reused. In addition, developers and testers should know the service-level requirements of the Web pages they are designing and testing. This ensures that caching aspects are considered at the outset, rather than retrofitting caching considerations later in the project.