August 2007 Archives

Here's an interesting article by Yahoo: "Thirteen Simple Rules for Speeding Up Your Web Site". While you may not be able to optimize some of the ALUI portal's less-than-stellar behaviors related to performance (really, 1+ Megabyte .js files?), these tips can help eke out even more performance from your custom code. Some aren't really relevant to custom code being served through a portal server (such as “use a Content Distribution Network"), but many are (such as "GZip Components" and "Make JavaScript and CSS External").

The interesting thing to remember here is that from a web browser's perspective, your portal is just a web site, subject to the same caching rules and performance limitations. Most optimizations you read about for web sites can be applied to your own site.

"A poor craftsman blames his tools". While I don't know who exactly to attribute that quote to, I do know that the corollary to the rule is that the right tools can make the craftsman. A feature we plan on bringing to this blog is a bunch of "Cool Tools" entries to share some of our experiences with the software that makes our jobs easier.

Kicking this off is Firebug, a Firefox extension that allows you to view the JavaScript, HTML, DOM, style sheets, and a whole lot more in your portal pages:

A really cool feature of Firebug is its ability to display the load times for all the components on your portal pages with a graphical representation of how long each component took to download. For example, check out the image below of a capture for the Plumtree Portal:

Notice the portal page itself (server.pt) was only a fraction of the total load time for a page. It's also interesting to see how the browser starts loading the JavaScript files before the HTML for the portal page is even downloaded, and how the browser can download multiple static files (images and js) at the same time to increase performance. Remember all this when you're thinking about site optimizations - sometimes the easiest gains can be made by optimizing parts of the site that aren't even physically on the portal server, such as external images and JavaScript.

It's definitely worth the free download at Firefox's Add-on Site.

Here's an undocumented little trick for debugging database transactions. The .NET ALUI portal uses DataDirect's ADO.NET database drivers for Oracle and SQL Server, so there are some settings that can be used to extract a lot (a LOT) of logging information about the state of the connection pool and SQL queries being executed.

Note that because this configuration can generate over a hundred megabytes a minute (!), this should just be used temporarily for debugging purposes.

Simply add the following lines to the database component section of the %PORTAL_HOME%\settings\common\serverconfig.xml file:

    <setting name="database-connection:trace-enable">
      <value xsi:type="xsd:boolean">true</value>
    </setting>
   <!-- java/ado.net trace file.  Required if trace-enable true -->
    <setting name="database-connection:trace-file">
      <value xsi:type="xsd:string">c:\temp\trace.out</value>
    </setting>

One of the most-overlooked concepts in multi-tiered architectures like the ALUI portal is caching.

I am constantly reminding clients about the nature of the HTTP transactions made for a portal page: "browser to portal, portal to back-end server". I've touched on the first transaction a bit (more to come on this!), but today I wanted to remind you about the "portal to back-end server" part.

Remember that when you make a request for a portal page with portlets on it, the portal will make multiple HTTP requests to the back-end servers for the HTML to render in that page. The trick is understanding that the request that the portal makes is very much like a web browser request, and handles caching in the same way. This means that your custom code should use the appropriate HTTP headers to tell the portal how to cache the HTML so that it doesn't need to make the request again for a certain amount of time, for a different user, or for a different page. The ALUI development documents talk about this in great detail; check them out!

If you don't have control of the code on that back-end server, though, another option is to override (or augment) those settings by editing the web service and specifying minimum and maximum cache times, as seen here:

By specifying a minimum cache time, you're basically telling the portal that once it gets the HTML the first time, it can wait for that long before actually making the HTTP request again to the back-end server, which can greatly increase the response time of the portal to serve up content to the end users.

For another fantastic article written on this topic, check out the "More than 5 seconds on Caching" article written by Ross Brodbeck on BEA's Dev2Dev site.

Logging is an important part of portal diagnostics. In addition to using PTSpy for real-time diagnostics, the ALUI portal now ships with a Plumtree Logger service that can capture events and record them to a file. The great thing about this service is that it uses log4j to configure how and what events are recorded.

Unfortunately, in many cases the default logging configuration isn't adequate. The default logging for the portal is to roll over daily, and in some cases with heavily used portals this can cause the log files to exceed hundreds of megs a day, which means you can't even open them in PTSpy to view all the information. The good news is that log4j is easy to configure - instead of using a "DailyRollingFileAppender", you can use a standard "RollingFileAppender". This allows the logging to roll over when the file hits a certain size, not just once per day. That way, you can configure the logging service to maintain a finite set of logs with a managable size.

To configure this, open %PORTAL_HOME%\plumtree\settings\ptlogging\ptLogger.xml. Study the file to see how the various appenders and filters are configured, and follow these steps:

1. Change the name and class of the PortalDailyLogFile appender:
             <appender class="org.apache.log4j.DailyRollingFileAppender" name="PortalDailyLogFile">
   to:
             <appender class="org.apache.log4j.RollingFileAppender" name="PortalRollingLogFile">
2. Change the filter to use this appender:
             <filters appender="PortalDailyLogFile" server="portal.nas-vm.Administrator">
   to:
             <filters appender="PortalRollingLogFile" server="portal.nas-vm.Administrator">
3. Remove the "DatePattern" parameter (we're not going be rolling over based on date, just size):
             <param name="DatePattern" value="'.'yyyy-ww"/>
4. Change the "Append" parameter to "true" so that the logs aren't overwritten when the service PT Logger Service is restarted:
             <param name="Append" value="false"/>
   to:
             <param name="Append" value="true"/>
5. Add the following lines to the appender to determine how big the file should be before it's rolled over, and how many files to keep at any time:
             <param name="MaxFileSize" value="50MB"/>
             <param name="MaxBackupIndex" value="10"/>
6. Restart the PT Logger Service. The new logs will be recorded to %PORTAL_HOME%\ptlogging\logs\portal\.

Remember these are all standard log4j configurations, so you could change the layout of the logging, log to a database, even set up logging to email you when fatal errors occur.

Ever run into problems downloading the portal installer on a Windows 2003 Server? By default, IE has "Internet Explorer Enhanced Security Configuration" enabled, and when you start up IE you see this message:

When you try to download an installer, you get a message at the top of the browser window that says "Your current security settings do not allow this file to be downloaded".

There are two ways around this. First, you could copy the installer to a local client and upload via a file share, or you could temporarily remove the Windows Component preventing you from downloading directly. This is done through "Add/Remove Programs", then "Add/Remove Windows Components". Uncheck the "Internet Explorer Enhanced Security Configuration" box, finish out, and restart IE. Remember to re-enable it when everything is set up!

Also, for those inclined to take a look, there's an interesting (and very long) MS White Paper on the topic.

Errors are never pretty to users who just want their portal to work. But sometimes they're inevitable, such as when a user cancels the Basic Authentication prompt when SSO is configured in the portal. Here's how you can make them a little prettier.

All app servers (we'll use IIS in this example) allow you to customize the page that is displayed to the user when certain failures occur, such as 401 (Access Denied), 404 (Not Found), and 503 (Service Unavailable). So rather than see an error like the following, you can present the user with a clean, branded error page suggesting other courses of action (close and reopen the browser, refresh the page, link to the main portal site, etc.).

In IIS you do this by going to the web site in IIS Manager and right-clicking, then choosing "Properties". Then click on the "Custom Errors" tab and you can customize any error page you'd like - just create a new HTML file and direct IIS to point there. Your HTML page should use the same look and feel as the portal so even when errors occur, the user experience is consistent.

Similar tweaks can customize the error pages in Weblogic and Tomcat for the Java versions of the portal. Don't forget this setting can also be useful for custom portlet code on the remote tier!

Incidentally, IE users often won't see this custom error page due to a configuration on their client. In these cases, if an error code is returned from the server, IE will show its own (useless) error page rather than the one you've put together. This option can be turned off in IE by going to Tools:Internet Options, then clicking the "Advanced" tab, and unchecking "Show friendly HTTP error messages".

One of the best ways to get ideas on what can be done with the ALUI portal is taking a look at other portals. Sure, most of them are installed behind the corporate firewall and are inaccessible to the rest of us (with the exception of some screen shots or live demos at events like Bea World), but there is an entire treasure trove of other portals out there being used as extranets, and are open to the public.

So how do you find these other portals out there? Your trusty global conglomerate search engine Google! While Google doesn't do a great job of crawling ALUI portals due to the complex URLs used (more on this later), it can usually index at least a couple of pages from a portal site available on the internet. And virtually all these sites have one thing in common: their URL contains the string "portal/server.pt" in it. Googling allinurl:portal/server.pt will return thousands of hits and probably hundreds of sites that you can use to see what others are doing well, and what can be improved!

Happy hunting!