Turbo for portals

First impressions are important, particularly in the case of customer portals on the internet, because long loading or response times or error messages when certain functions are accessed try the patience of even the most tolerant user. But the risk of performance problems increases particularly as a result of the complexity of powerful portals – such as SAP NetWeaver Portal – which integrate a number of different applications and backend systems. At the same time, it is not easy for system administrators to measure portal performance reliably or determine the cause of poor availability.
Even though most applications and backend systems achieve availability of more than 99 percent, a single fault can have serious consequences for the performance of the portal.

The weakest link is critical

This can be demonstrated using the example of online banking. Most banks allow their customers to view personal account data over the internet. With SAP NetWeaver Portal, customers usually log on via a central point of access, where various iViews – reusable web components that display the relevant information from the backend systems – call up the financial data. One iView will display the current account details, for example, while another will display the savings account data. A third iView calls up data from a stock-market backend system in order to show customers the value of their portfolios. If just one of the applications that access the iViews fails, the iView can not be loaded, even if the other components of the portal are functioning perfectly.
The customer has the impression that the performance of the portal as a whole is not good enough, and makes a complaint to customer services. A quick check there using conventional administration tools reveals that the portal is working perfectly. From the point of view of the administrator, this really is the case, as the portal is functioning and can be accessed. Without an insight into the applications connected to the portal, the administrator is not able to determine the cause of the problem.
After a number of attempts at diagnosis, which can last several hours, the portal administrator will finally discover that one of the iViews contains an error. The administrator must then test each of the components individually until the problematic application has been located. The administrator then informs the application developer and waits for a solution. This scenario shows the effort involved in pinpointing and eliminating a performance problem.

Common faults

In very general terms, the potential problems in the portal can be divided into three categories. First, it is possible that SAP NetWeaver Portal is not staged correctly across several nodes as a result of HTTP and 404 errors because of the complex structures involved as of Version 6. Other indications of HTTP errors include null pointers, which refer to objects that do not exist. The situation is similar in the case of out-of-bound errors with a reference to an array index that does not exist on the web server. The error message “500 Internal Server Error” usually occurs if the portal attempts to refer to a component that does not exist on the server or is incorrectly named. As most IT environments are subject to constant change, it may take days to diagnose errors such as these.
A second possible reason for poor portal performance relates to problems in the applications displayed in the iView. While the user gets the impression that the various iViews themselves take a very long time to appear, the causes for this may lie in the application logic running in the background. It is not obvious which point in the transaction stack of a Java Virtual Machine is causing poor performance. The portal administrator has no way of quickly restricting the possible causes of the error, and must carry out a time-consuming diagnosis.

Problems in the backend

Third, the performance also depends on the “queried” backend. When a backend system – be this a database or data warehouse – is called that has not been correctly set up or is not responding, the performance of the whole portal suffers. This could be the case for example if data on the market value of a portfolio is extracted directly to the iView from a “slow” non-SAP system.
Occasionally, the enterprise portal does not harmonize with the backend system in question. Most of the information flow between backend systems and the portal takes place via SAP Java Connectors (JCOs), which enable Java systems to communicate with any SAP Java application. Slow servlets or interrupted connections adversely affect the performance of the JCOs and block communication.
Alongside JCOs, synchronous database queries – known as database threads – may also slow down the enterprise portal. If there are not enough threads in the database queue, more and more delays occur. The long response times between the applications and the database also adversely affect the performance of the portal.

Automatic performance control

Portals deliver the technology that enterprises use to provide coherent, web-based services for their customers, partners, and employees. However, because the solutions for enterprise portals are becoming more and more complex, the requirements relating to the management of performance and availability are also increasing. Special tools and processes ensure that portal-based applications constantly provide the expected business value. A solution of this kind must provide real-time data on the portal performance from the user’s perspective. It must also display all transactions across the complete application architecture of SAP NetWeaver Portal for business users – known as application owners – and IT employees.
The Introscope solution from Wily offers this support. It makes it possible to monitor complex web applications and identify problems at an early stage. Introscope obtains metrics from Java applications directly at bytecode level by enriching the bytecode at runtime with measuring points about the methods, runtime, and number of method calls. The measuring points, known as “probes”, are read out using an agent that is part of the virtual machine and are sent to a central processing component. The measurement therefore has no negative effects on the application performance.
The runtime values on the metrics for the call duration or number of calls can be visualized using dashboards for the various target groups. For example, system administrators call up information on availability or compliance with various service level agreements, while developers access detailed data on the runtime behavior of certain objects or the relevant methods. The various stakeholders therefore receive different views based on the same information set: portal performance is under control at all times.

Christian Glatschke
Christian Glatschke