Show TOC

 Web Dynpro Java Performance Analysis: Resource ConsumptionLocate this document in the navigation structure

Problem Description

A Web Dynpro application requested via a URL is responding but takes a long time to process. In other words, the experienced response time for the user is longer than expected.

Scenario Type:

Performance Analysis

SAP NetWeaver Component:

SAP Web Application Server: Java Web Dynpro (BC-WD)

Validity:

SAP Web Application Server 7.00

Overall Web Dynpro Architecture

Possible Error Sources

  1. Browser issues
  2. J2EE Engine is overloaded and responds too slow
  3. The J2EE server settings are sub-optimal
  4. Insufficient Web Dynpro Framework performance
  5. Insufficient application performance
  6. Unacceptable back-end performance
Decision Roadmap

Prerequisites

You should have access to the J2EE Engine as an administrator.

Main Tools

SAP NetWeaver Administrator

Analysis

1. Browser Issues

The first step is to check the client (browser) performance values. Depending on the rendering type and browser, this analysis may differ.

For SSR (standard) browser clients, use the URL extension to see performance values in the browser status line: sap.session.ssr.showInfo=true

Tip

http://localhost:50000/webdynpro/dispatcher/local/_test_sapicons/IconApplication?sap.session.ssr.showInfo=true

This will result in some basic information about the time consumption of the browser, the J2EE component and the backend (elapsed time in [msec]). This gives a good indication whether the browser or the browser PC (for example, too few resources) is part of the problem.

2. J2EE Engine is overloaded and responds too slow

If too many hits per seconds are directed towards a J2EE Engine server, performance may degrade. See the HTTP log of the engine to get a picture of the incoming requests per second. If there is little traffic and the engine's reaction remains slow, you have to continue looking further into the engine, the framework, and the application.

It is an option to temporarily use a standalone (additional) J2EE server with no traffic for the same application. If the performance issues persist, you can exclude the engine's load situation as the origin of the problem.

3. The J2EE server settings are sub-optimal

To optimize the HTTP request processing for Web Dynpro applications check timeouts and sizes. This is for example important if you have integrated a business graphic into the Web Dynpro view since usually these graphics are large images. The response times depend heavily on the settings for the values ServletsLongDataTransferLimitandServletsLongDataTransferTimeout.

More information: Long Data Transfer Mechanisms

4. Insufficient Web Dynpro Framework performance

The Web Dynpro runtime has been optimized for short round trip and server processing times. You can monitor performance numbers in the running and productive system by using the Web Dynpro Console.

Use the Web Dynpro Console which you can start on the engine via the following URL:

 http://localhost:50000/webdynpro/welcome

The advantages of the Web Dynpro Console are as follows:

  • It offers a browser access to the data
  • It is focused on Web Dynpro and its application
  • You do not need administrative privileges to see some key numbers

The following example shows the framework numbers for two simple round trips on a laptop:

Note

When you check the framework, it is important to know that the first request on a freshly started engine and the logon via SAP User Management Engine takes extra time.

5. Insufficient application performance

Drilling down to Performance → Application, you can select the package name or component name of your application and investigate which event handler contributed significantly to total time consumption. Note that you can also have a look at the Web Dynpro framework times from here: Go to Performance → Server, the Times per User (Performance → User) or the Times per Request: Performance → Request.

6. Unacceptable back-end performance

Performance measurement of the back-end connections is available for the Remote Function Call (RFC) model. Go to Performance → Model & Backend to trigger and check the measuring of the RFC communication.

The Console shows how many times and with what response times the Java Connector (JCo) calls to SAP systems have been executed. It indicates the fraction the Dictionary metadata transfer contributed to the overall time. Default setting for the back-end call measurements is off and needs to be turned on.

Note
Note For RFC measurements in the ABAP back-end system use the transactions ST05 (Performance Analysis/RFC Trace) and STAD (Business Transaction Analysis).

For other back-end types such as Web Services or EJBs you need to adapt your model coding manually.

More Information