Web Dynpro Java Performance Analysis: Resource Consumption 

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
NetWeaver Component:	SAP Web AS: Web Dynpro Java (BC-WD)
Validity:	SAP Web AS 6.40

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 or too many back-end calls

Decision Roadmap

Prerequisites

You should have access to the J2EE Engine as an administrator. For a detailed analysis you need to have WebDynproAdmin permission granted to your user account (starting with NetWeaver Stack03) and access to the Visual Administrator of the J2EE Engine.

Note that every J2EE Engine administrator implicitly has WebDynproAdmin permissions but not vice versa.

Main Tools

Visual 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

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 (IE or Netscape/Mozilla) or the browser PC (for example, too few resources) is part of the problem.

For CSF clients (only supported up to NetWeaver04 Stack02) see also SAP Note: 578397 

2. J2EE Engine 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 there are timeouts and sizes that can be set. You can check and modify them. In particular, if Web Dynpro is used with business graphics (large images) this can become important: Response times depend heavily on the settings in point 2 in the listing below:

Check in the Visual Administrator:

       1.      Server/Services/HTTP Provider compression for .js and .css file can be turned on

This increases the overall performance with the focus on the initial requests where most style sheet content and JavaScript is sent to the client. By default, the engine delivers these file types uncompressed mainly for backward browser/HTTP compatibility reasons.

       2.      Server/Services/Configuration Adapter  ®  Configuration  ®  /cluster_data/server/cfg/services/PropertySheet.http the value: ServletsLongDataTransferLimit and ServletsLongDataTransferTimeout

If the transfer limit (between the dispatcher and server) is too small, the images are not transferred with sufficient speed. Starting with NetWeaver Stack 04, the engine is delivered with values that are sufficient for small and medium-sized images. As a simple rule, the limit should be larger than the largest image size.

4. Insufficient Web Dynpro Framework performance

The Web Dynpro runtime has been optimized for short round trip and server processing times. To make the framework performance transparent, the Web Dynpro runtime inside the J2EE Engine is instrumented with JARM. This allows you to monitor performance numbers in the running and productive system. The standard instrumentation is limited to the major steps and has minimal impact on the processing time itself. The instrumentation allows you to see which part of the request cycle might be causing the problem. As inside the Web Dynpro request cycle application event handlers are called in turn, they can contribute to the load (see the next topic for details).

In order to see the Web Dynpro performance measures, use the Visual Administrator or the Web Dynpro Console. Here the Visual Administrator is used:

Select Server/Services/Monitoring  ®  Root/Performance/Application Responsetime/Component Content :

Visual Administrator visualizing Web Dynpro framework performance

 

You will find times in msec and how they distribute over the request cycle steps.

If the numbers indicate main contributors as phases named:

●     com.sap.tc.webdynpro.runtime.MainTask.Phase.Application.init

●     com.sap.tc.webdynpro.runtime.MainTask.Phase.Event.Application

●     com.sap.tc.webdynpro.runtime.MainTask.Phase.View.doModify

then most likely the application needs further inspection.

This is the next step in the analysis.

If, on the other hand, time is spend insight framework phase methods such as ..MainTask.Phase.Rendering, ..MainTask.Phase.Navigation or ..MainTask.Phase.Validating, the Web Dynpro Framework has a performance problem. It is hard to describe a range of values that indicate a well-functioning and performing framework (as opposed to a one that is not performing well). The complexity of the screen as well as the navigation type and the input validation play a role. The numbers in the picture show two (see NoCalls) Web Dynpro framework requests on a 1GHz CPU displaying the Web Dynpro Console application itself (no other apps running):

Framework numbers for two simple round trips on a laptop

When you check the framework, it is important to know that the first request (on a freshly started engine) and the logon via UME always takes extra time and it makes sense to reset the JARM measurement before the action in question takes place.

5. Insufficient application performance (for development scenario only)

If you think the application itself is the origin of the delays, you need to identify the methods that contribute most to this. In the event-driven programming paradigm, the application is only activated via event handlers. So the Web Dynpro Framework allows you to include the application event handlers in the instrumentation when required. They are not turned on by default to reduce overhead.

To turn on the application performance measurement, you have to have access to the source code of the application and have a NetWeaver Developer Studio installed.

First you have to turn on the auto-instrumentation of your code in the IDE. Starting with NetWeaver Stack 03, this can be done by setting the JARM level of the application in the IDE to a value between 5 and 10 (meaning the level of detail):

 

Setting the JARM level for generated applications in the IDE

 

Then you can rebuild your project (not DC build but local build), deploy and run it afterwards.

 

In order to see the additional output, use the Web Dynpro Console which you can start on the engine via the following URL:

 http://localhost:50000/webdynpro/welcome  ®  Web Dynpro Console

The advantages of using the Web Dynpro Console for monitoring versus the Visual Administrator tool 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

Web Dynpro Console information on application performance

 

You can also reach the Web Dynpro Console from the Web Dynpro Welcome page:

http://localhost:50000/webdynpro/welcome again assuming that your engine port number is 50000 (corresponding to instance 00).

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 view 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. These are basically different views on the performance data.

Web Dynpro requests in the Web Dynpro Console

 

If this does not analyze your code thoroughly enough, you can instrument manually the coding sequences you might want to see in more detail by using JARM.

In order to read and use JARM data properly, you need to understand the difference between gross and net time of a method or component. Gross means the overall time that has been consumed including all subroutines/methods. Net is the time that is calculated when all the inner times are subtracted from the gross time.

6. Unacceptable back end performance

Performance measurement of the back-end connections is available for the SAP RFC Model only (starting with NW Stack 04). In the Web Dynpro Console Performance  ®  Model & Backendyou can trigger and check the measuring of the RFC communication.

The Web Dynpro Console shows how many times and with what response times the JCo calls to SAP systems have been executed. It indicates the fraction the metadata transfer (DDic Information) contributed to the overall time. Measuring back-end performance is turned off by default.

Checking performance in the back end clearly depends on the back-end type that you are using. For the most common case (the SAP ABAP type back end) the tools are well-known and established.

●     Transaction ST05 to start a RFC trace

●     Run the application that needs to be measured

●     Stop the RFC trace

●     Visualize the results in ST05 (see also transaction STAD for more details)

●     If  the engine and the back-end system are connected via an monitoring agent (see Supportability Setup Guide for details) you can find the raw statistic records with transaction STARTTRACE  ®  Server selection  ®  Time selection.

Checking the trace of an application in the backend is a typical case for using the single activity trace (SAT). This passes the trace flags via RFC to the back end and if the back end allows inheritance of trace levels, the traces should be automatically created. JARM contributes the trace data to the Java-side of this trace. You configure the SAT in the Visual Administrator (Performance Tracing  ®  Tab = Trace Config  ®  SAT) and you can check the trace results with the Log Viewer.

For other back-end types (such as Web Services or EJBs) you need to instrument your model coding manually, in much the same way as the application was instrumented manually.

Additional Information

CSN components and notes

Further information can be found in the CSN system. The notes for Web Dynpro Java Runtime use components BC-WD or BC-WD-JAV.

Documentation

Web Dynpro Console