ALUI Performance Commentary

Performance in the portal is a tricky subject, at best. There are plenty of external (and internal) factors that can contribute to poor performance, or the perception of poor performance and unfortunately for the conscientious system administrator, developer or project manager, it's not always easy to tell where the bottlenecks are.

Performance Comments

One simple thing you can do to analyze what is going on with your page performance is check the comments. What I mean is, by default there are performance comments built into every page in the portal (they can be enabled/disabled in your portalconfig.xml). Usually, they look something like this (these were taken from http://portal.plumtree.com/):

<!--Hostname: prodweb17--><!--Total Request Time: 1953
Control Time: 0
Page Construction Time: 1922
Page Display Time: 16
--><!--Portal Version: 6.1.0.253366, Changelist: 253366, Build Date: 04/02/2007 at 08:30 AM-->

All well and good, right? But what do these numbers mean? How about I start by quoting one of our internal knowledge base articles:

• Total Request Time is the total time it took to process the HTTP request.
• Control Time is the time it took for the MVC Control to process the request. The Control Time will be equal to -1 if no Control was called (i.e., the request went directly to the MVC View).
• Page Construction Time is the time it took to construct the HTMLPage for display.
• Page Display Time is the time it took to actually render the HTMLPage into HTML and write it to the HTTP Response.

Hmmm. Okay, how about a "revised standard English" version? As usual, I'm relying on various Gerald Kanapathy comments and my own testing and breakdown of the portal source code for this info:

• Total Request Time - This is everything, basically a sum of all the below times.
• Control Time - This is just the time it took to make decisions for the page. A lot of times this is going to be pretty low unless there are postbacks or things going on in the background. Usually custom PEI's and other logic will be executed here.
• Page Construction Time - This is pretty much everything else, including how long it took to request HTML from all the portlets on the page and how long it took to render any transformer tags on the page. You will see a big reduction in this time the second time you hit most pages because of portlet caching.
• Page Display Time - This is almost always very low (30 ms and lower, at least) and is pretty much a measure of network latency and performance of your application server. I don't think it really takes client-side latency into account, so I recommend you measure this using something like Yahoo's YSlow Firefox Plugin.

If you *really* want to be sure of these times and where custom code you wrote is executing, I recommend doing something simple like adding a 5 second Sleep statement in your PEI/Server API code/Portlet and seeing how it shows up in the page performance comments.

Another interesting note here is that these comments can help you diagnose image server problems. If your page request time is low but you still experience slow request times, you can start looking toward the image server for issues. Yahoo's YSlow Firefox Plugin is, again, a great resource for this (and for getting suggestions on performance improvement).

Is This Enough?

Although the comments can be very useful in diagnosing where a problem starts, they don't seem to be nearly enough, nor are they very specific. For instance, if there are 7 portlets on a page, which one is causing the construction time to whack out? Are my custom tags causing construction time problems or is there a lag in my remote portlet response?

As is normally the case here, I wouldn't ask the questions if I didn't already have the answers. In this case, my answer is that we can add our own performance comments to the page in the form of portal component replacement.

Since writing a portlet performance plugin turned out to be more challenging (and interesting) than I thought, and since I'm a sucker for cliffhangers, you'll have to wait 'til next time for the explanation....