Best practices for designing store pages that contain MVC Portlets
WebSphere Commerce provides a set of sample portlets as building blocks to demonstrate the use of the JSR 168 standard and to communicate with the WebSphere Commerce services from the WebSphere Portal server. A sample Portal page layout recommendation is also provided, to demonstrate a shopping experience similar to the ConsumerDirect store. This page layout is designed to demonstrate the technology in JSR 168, such as portlet-to-portlet communication and the use of standard portlet libraries. This design may be only suitable for a low to medium traffic sites, such as in a business-to-business shopping scenario. However, in a popular site where usage traffic is relatively high, it is necessary to come up with an alternate layout to separate user specific content, which cannot be shared across the entire site, from the common content, such as categories and various product items. This allows for the best caching strategy and technique to be used for each type of content in the Portal environment.
In a typical low traffic shopping site, the site designer will present as much related information about the same page as possible to the end user. This makes the shopping flow more efficient, while at the same time reducing the rate of abandoned orders. WebSphere Commerce recommends the following page layout arrangement for a low traffic site:
This layout has the catalog navigational information, product information, order information, as well as user profile information all on a single page. A typical shopping can be completed with just a few clicks and a few page refreshes.
From a Web development point of view, the ideal Portal web site would enable content providers and administrators to provide content to site visitors without having to consider the delivery characteristics of the content. Content and applications would ideally be provided in such a way that the information would automatically be delivered to a site visitor in the most convenient and applicable manner. Performance and scalability considerations for high volume, high performance Web sites, such as business-to-consumer sites, made it necessary to make a distinction between static content and dynamic applications. This is because different caching technologies should be used for delivering static content and dynamic applications.
Avoid serving static content by application server
Static content provides the same information to all users. In many cases, static content is stored in HTML files or in the form of a binary image file on a server, which users access using Web browser clients. Although the application server can technically serve up this static content, doing this will increase the workload on the Portal application server and therefore reduce the overall performance of the WebSphere Portal site. Serving static content with an external source, such as a web server, cannot only reduce the workload on the application server, but that external source can also filter out unnecessary traffic and free up network bandwidth.
Avoid mixing sharable and non-sharable content on the same page
Dynamic content generated by an 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's profile 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, such as full page caching.
In a typical high traffic Portal site, all catalog browsing and product information can be grouped into one set of portlets to be displayed on a single Shopping page, while the Portal user's specific information, such as the shopping cart and account information, can be placed on other pages. An example of this is shown below:
The following are a few additional suggestions that a Portal designer needs to consider when planning and designing a new Portal site to work with the WebSphere Commerce Server.
Perform update in action phase only
The WebSphere Commerce integration with WebSphere Portal programming model suggests the use of Process and Change service requests through the MVC Portlet action, while Get requests should be done through render requests from the JSP getData tag. This is to avoid potential deadlock situations from happening while performing a long running action request that may cross reference other resource dependencies generated by other portlets on the same Portal page.
Avoid adding too many portlets to a single page
The CPU time required to generate a page is greatly influenced by the number of portlets on that page. 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. For pages with many portlets on them, determine whether the page could be split up into several pages, distributing its portlets across those pages. One way to make this decision is to think about whether users will need to access all the applications on the page at the same time. If not, then it may be possible to break the page up into several pages.
Avoid overloaded themes
Themes and navigation bars are a set of common elements that appear on every single Portal page. Themes contribute a significant portion to the overall render payload and it is important to consider carefully what to include and exclude on the theme to be used for your WebSphere Commerce Portal pages. WebSphere Portal provides a default theme and skin that demonstrates the portal server's rich set of functions. If your portal site does not require all of the functionality provided by the shipped themes and skins, you can realize performance benefits by selectively removing some of those functions. See the Performance guidelines for themes and skins topic in the WebSphere Portal Server information center for more information.
Avoid 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 may result in causing significant overhead due to the triggering of portlet wires. In a high traffic site, if portlets on a frequently accessed Portal page require the use of portlet wires, one way to remedy its side effect is to make use of caching.
Avoid large JavaScript
JavaScript must be parsed and interpreted by the client, so very large JavaScript files (thousands of lines) can take a long time to be processed even if they do not contain complex logic.
Avoid unnecessary Drag-n-drop operations
Drag-n-drop is a new feature in WebSphere Portal Server v6.0 and this feature can 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 the drag-n-drop feature, you can consider using an appropriate caching strategy to allow the application server to re-use the generated code if possible.
Plan your caching
Caching is best done as a planned activity, not as something that is retro-fitted into an existing application. Consider a newly developed system that is performing poorly when placed under projected production system loads. When this happens, it can then become a major exercise to change the application in order to remedy the problems. If you are expecting significant site traffic, be certain to spend sufficient time analyzing the performance requirements in the early stages of development. This will help you to meet the project deadline with the delivery of a high performance system, not just a functioning system, and will ensure that you create a Web site that satisfies your end users. The best candidates for caching are operations that are large, slow, or resource-intensive to produce. When evaluating potential caching candidates, make sure that they are publicly accessible. The more users that can take advantage of a given cache entry the better. Do not cache pages that are never reused. Make sure developers and testers know the service level requirements of the Web pages they are designing and testing. Have them consider caching aspects at the outset, rather than retro-fitting caching considerations later in the project.
Related concepts
WebSphere Commerce integration with WebSphere Portal
Customizing WebSphere Commerce Portal integration
WebSphere Commerce Portal integration event handlers
Related reference
WebSphere Commerce portlet samples
Last updated: 25 November 2009