Portal Application Performance 

Observed and Real Performance

Performance can be into performance sensed by the users and performance from a technical point of view.

Performance sensed by the user is difficult to judge. Several psychological factors come into play. The most important performance issue for user is the delay between a user action and the response.

Examples:

·        Time from the start of an application until it is ready to use.

·        Rendering time of a Web page in a browser.

·        Time to load a pop up menu to select user input.

If an operation is more time consuming the user should be informed as follows:

·        What operation is currently in progress.

·        Progress bar.

·        Percentage already processed.

·        Estimated time when the task is finished.

Portal applications using these techniques are usually rated “quick” by the user, although it is slow from the technical point of view.

When portal applications need information from a backend system it is important that the applied query is efficient and fast and that the application avoids querying the same information several times.

Summary:

Technical performance can be improved with efficient algorithms, fast connections and clever caching.

Caching

The term caching refers to all strategies that hold recently-retrieved data to avoid the overhead retrieving the data again. For portal applications caching is used then accessing backend systems.

Example:

A portal application displays the current temperature that is provided by the commercial weather-service Cats-and-dogs.com based on WebService technology. The portal application will update the temperature in a five minute interval. Since the temperature is independent from the username, the values will be queried only once from the weather service and stored for all users in the portal. The portal application has to do the following:

1. Keep the weather values in an area that is shared by all users on the node: portal application class.
2. The weather values have to be accessible for five minutes.

Because of the cache the weather-service is called every five minutes and not for every user that accesses the weather portal application.

Areas relevant to caching are:

Scope: User, role, group, application, area, country

Expiration: fixed interval, time-based, never

Survival criteria: size, usage frequency, last usage

Representation: raw data, business-level data, presentation-level data

Following data sources should be cached:

·        Databases

·        Connected SAP backend systems

·        File I/O

·        Any kind of data that is retrieved through network connections.

The representation of the data in a cache is also important. For the weather portal application example can be implemented with three different cache levels:

...

       1.      The lowest level would only cache the raw data obtained from the weather service which is the XML document containing the response to the most recent query. The advantage is that the entire message is stored and no information is lost. The disadvantage is that the needed data entry has to be extracted every time when the temperature value has to be refreshed.

       2.      On the business level the object containing the weather data in a normalized form is cached.

       3.      On the presentation level the weather data is cached in the form it is displayed. If the portal application displays the data in a common layout, the entire HTML page with the current business object state can be cached, instead of generating the HTML page out of the business level data again and again.

 

Caching Scopes

As described above the SAP Enterprise Portal offers various places to establish a cache (for example, request or session context). Generally speaking, a cache context should be as wide as possible but it must consider the following  logical and performance issues:

       1.      What is the cache eviction (or timeout) policy and how is outdated data handled (prefer a quick check over notification patterns).

       2.      A cache must never grow unlimited! The implementation of the cache has to limit the number of objects / entries kept in the cache. Memory is a very valuable resource that is needed to process requests and not to store data that has already been accessed once before.

 

Deferred Initialization

The rendering time of a portal page is a big issue. A portal page often contains several portal applications. The user will most likely not use all displayed portal applications. Therefore it is very important that all portal applications used on a portal page initialize and render fast. The initial display of an portal application should not collect extensive data. This should be done on demand. This will improve the overall speed of page rendering for the majority of users.

Portal Applications on the Start Page

The start page is loaded right after the user has logged on to the portal. Because the start page is displayed quite frequently it must have a good performance. Following rules apply for the start page:

·        Data initialization has to be reduced to the absolute minimum.

·        The start page should have a lean layout to speed up the initial rendering.

·        The memory footprint must be as low as possible (not more than 1 MB) because there will be several active instances at once.