Portal Sites

A portal behaves differently from other sites in that it offers a personalized "home page" to users. Much as they do on the B2B web site, users tend to log on at the beginning of their day and stay logged on all day long. They refresh their customized page from time to time during the day and drill down into items that catch their interest. These sites often display a customized view of news, entertainment features, a few selected stocks or other investment data, weather, and so on.

Such sites may forward requests for page segments to other systems and web sites. For example, a portal might have a page link that forwards requests to a news or stock price site. Public portal sites sometimes support millions of registered users, while enterprise portals frequently support tens of thousands of users.

Although portals support many users, these users make fewer requests against the portal than e-Commerce or financial users. In fact, the traffic patterns for a portal web site often resemble those for a B2B web site: many concurrent users making infrequent requests.

Caching Potential

Portals make extensive use of caching. They cache static content for faster display and refresh the cache periodically to reflect updates. The dynamic portions of the portal web site often cache small, dynamic components of the portal page for faster display, particularly if all the portal users see many of the same components .

Special Considerations: Traffic Patterns

The web sites accessed via a portal server impact the portal's behavior. However, the portal traffic pattern often differs from that of the other web sites we've discussed thus far. While the overall daily traffic patterns for a portal mimic the B2B traffic patterns we discussed earlier, portals also often experience peak traffic periods. Especially for enterprise portals, most users arrive at work within a one- or two- hour interval and log on to the portal web site for the first time. User log-on is the most expensive operation for many portals. During this process, the web site interacts with security servers (like LDAP) to retrieve information needed to confirm the log-on. The web site creates the user's session information during this time and also loads any personalization data for the user.

Beyond the morning log-on traffic, these web sites often receive event-based load spikes. For example, if the CEO makes an important speech, or the company releases a hot new product, an enterprise portal receives more traffic as employees clamor to see this information. In addition, portals sometimes generate their own load. Often portal pages include JavaScript to refresh key page components periodically. Also, some components include applets, which generate load against the web site. Understanding the typical configuration of a portal page helps in designing the performance test.

Performance Testing a Portal Site

Many of the principles behind testing a B2B web site also apply to testing portal web sites. The test requires many users to simulate the user pressure, and it usually benefits from scaled-down testing. However, portal web sites sometimes run two sets of performance tests. The first test resembles typical daily activity (the user logs in and makes infrequent requests). The second test just simulates log-on activity to accurately test the log-on peak in the morning.

Because these web sites rely on remote systems to supply content, security, and personalization data, coordinating your test with the support organizations for these systems is critical. As with the e-Commerce web sites, testing at off-shift hours often works best. Likewise, portal performance tests often simulate content from third-party providers.