by Adam Kewley, Senior Consultant
Part of the difficulty with any application design is ensuring that it’s scalable. Sure your app may have originally only been intended for twenty or thirty people, so efficiency wasn’t an issue. At least not until other teams caught wind of it, and then suddenly everyone in your organization wants to make use of your dashboard. Perhaps your manager eventually decides to incorporate your app into a larger portal, which has a much larger audience than you originally intended. Or perhaps its services got consumed by external sources that were not part of the original scope plan. Whatever the case, needs and demands change over time so it’s best to ensure that your implementation is able to scale, up to a certain point.
During general development, it’s a good idea to keep the footprint of the portlet and portlet WAR in mind. Efficiency is relative and your app will only go so far, but there are a few pitfalls you can avoid which will ensure that the application isn’t being bottlenecked.
First we’ll start with the largely unknown and unexpected.
By default, the SQL call builders in WEF enable the paged data retriever so that you’re only pulling back subsets of a record at a given time. This means that your 5,000 row report will most likely be storing tens of rows at a time. Unfortunately, since this silent feature usually goes largely unnoticed, sourcing records from other data sources (Web Services, SAP, LDAP, External data sources) may be incurring performance hits that you’re currently unaware of.
It’s important to know how much data your application is polling from various back ends. While database latency may be easy to spot, session size is usually an afterthought that comes back to bite when you least expect it.
Caching is a two-edged sword. It can be useful to cache common results to lower the stress on a back end system (especially one that’s performing complex calculations), but it can also greatly increase the memory footprint when not needed. By default, caching is turned off. Whether or not to enable caching largely depends on how the data will be used. Are you performing searches on a database, or pulling back part numbers that are largely static? Data that can be shared across multiple users will greatly benefit from caching. This can be enabled in the Service Operation builder.
Count your Requests:
Be mindful of the amount of times you’re calling various services. Perhaps your portlet is initializing twice and calling the same service more than it needs to. Switching from a detail to an edit page (for a record) doesn’t usually require a second poll to grab the same data. By adding logging statements to your service operations, you can actively monitor how often you are calling them
It’s common knowledge that WEF event declaration and event handler builders are typically broadcast event builders. What may not be known is that portlets on other pages are still actively listening for events. If you have a filter event that affects portlets across multiple pages, each portlet will process after the event is fired. Yes—even portlets on pages that are not currently rendered will catch and operate on the event. This can become a potential bottleneck for portals that actively rely on broadcast events. There are techniques for getting around this. If you are relying on filter logic that affects portlets on many pages, consider having each event handler check to see if its page is currently active before proceeding. Otherwise you’ll have many portlets polling for data at the same time.
WEF provides a comprehensive logging mechanism for further analyzing your application. Most of these are turned off due to the performance penalty they incur. Don’t forget to disable them after testing. Using WEF logging, you can tell how long an application is taking to regenerate. You can determine how long actions are taking to run (and in what order!), as well as obtain a session footprint for a single user. There are other logging features but these three will go a long way in helping you understand where your bottlenecks may lie.
The variable builder has many different ways to store and share data. You can store data in the request, in the session, across multiple users, and as static. In WEF the variable scope is sometimes forgotten but can be useful for taming session sizes. You can set the scope of the variable under the Advanced section of the variable builder. In addition, the Discardable and Shared variable builders should be looked at as well. Knowing when to properly use these can be tricky, so a good understanding of the application and architecture is key.
Fixpacks are collections of bug fixes that grow over the lifecycle of a given version of WEF. Upgrading to the latest fixpack can sometimes improve performance across the board. Fixes may include browser related performance improvements, server side, or session usage. The release notes for a given fixpack will have more information as to what issues are addressed. It’s always a good idea to upgrade to the latest fixpack if possible.
Offloading expensive transformations:
If you’re relying on WEF or Java to perform large transformations or calculations on data, consider moving this part to a staging server. Portal architecture recommends offloading taxing data operations to other servers, which will lighten the load on the portal server.
There are plenty of other good areas to focus on from a performance standpoint but this document provides a good starting point. Understanding how your application performs will not only eliminate bottlenecks but will also ensure that it continues to remain a valuable resource in the future.
For more information, please visit the following links:
- Best Practices: http://www-10.lotus.com/ldd/pfwiki.nsf/dx/performance-best-practices
- Techniques for Enhancing Performance: http://www-01.ibm.com/support/docview.wss?rs=3044&context=SSRUWN&dc%C3%9B520&uid=swg21268497&loc=en_US&cs=UTF-8&lang=en&rss=ct3044websphere
- WEF (Portlet Factory) Performance Analysis: http://www-10.lotus.com/ldd/pfwiki.nsf/dx/PortletFactoryPerformanceAnalysis.pdf/$file/PortletFactoryPerformanceAnalysis.pdf
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. Thank you!