Function1

A complaint that comes up all the time is “The portal is slow”. And from the end-users’ perspective, this can be true – users shouldn’t have to wait more than a couple of seconds for a page to load.

But that simple statement overlooks the fact that there are many different servers involved in the Aqualogic portal architecture. Unlike a simple web site, the browser is not just going to a single web server and loading static pages. Instead, there are a lot of other HTTP requests that happen behind the scenes that may be the culprit. So when someone tells you the “portal is slow”, keep in mind that the issue may not be with the portal server at all.

Take the following traffic flow diagram for a very simple portal page with a single Publisher portlet on it:

Here’s the basic gist of what’s happening:

1. Browser makes request for page; goes to Load Balancer
   
2. Load Balancer directs the request to a single Portal Server
   
3. Portal Server sees that there’s a header, footer, and portlet on this page; for each of them it makes an HTTP request to the “Published Content Redirector”
   
4. Published Content Redirector does a cache or DB lookup to get the published content URL for the content itself (header, footer, and portlet) and issues a 302 (Redirect) back to the Portal
   
5. Portal gets the 302 (Redirect) response and makes another request for the published HTML
   
6. In some cases, that published content can be code that goes and gets other content (say, a stock price to show up on the header)
   
7. Portal aggregates all the Remote Portlet HTML and builds a single page; returns to Browser through Load Balancer
   

Notice that in this example, there are roughly 10-12 HTTP requests that are actually happening, and if a slowdown happens in any one of these areas, the browser’s page request will take a long time, because the portal has to wait for all the remote portlets to return their HTML before it can generate its response. This is the main reason you shouldn’t set your web service timeouts too high – it’s better for a single portlet to time out and the user seeing an error message than for the entire page to time out in the browser.

Stay tuned – more on this in another post, include a much more comprehensive diagram!