Show TOC

8.1 Performance AnalysisLocate this document in the navigation structure



In the context of performance, logon is not considered separately, as it is a one-off process over the lifetime of NWBC running. Standard authentication processes are used for any other HTTP access to the server, for example, by Web Dynpro ABAP, BSP, and so on. Logon is very much influenced by the form of authentication used, for example, form-based authentication versus digital certificates. The logon is standard ABAP and not NWBC-specific.

Desktop Shell

NWBC for Desktop is a program running completely on the local client computer. On startup, it retrieves the navigation tree from the PFCG store with a few HTTP requests. After this, the shell has no further contact to the server, but caches the complete navigation tree on the client.


The program running on the desktop consumes about 100 MB of the main memory.


2 HTTP requests with a typical payload of 50 KB (this depends on the role setup) to read the complete navigation tree. Further sporadic small HTTP requests are fired to the server to resolve navigation targets that are needed to start additional applications. This data is fetched once on demand only and is from then onwards cached on the client.


1 ABAP session with a lifetime of 15 seconds and main memory consumption of approximately 3 MB.

Conclusion : The performance footprint on the network and server can be ignored as it is only relevant for the startup process. Only the client footprint is relevant for the desktop shell.

HTML Shell

NWBC for HTML is running inside a browser on the client. Each shell interaction triggers a roundtrip to the server to render the next view of the shell. This impacts both the network and server.


Browsers need minimal resources to render the HTML representation of the navigation tree. This can be ignored.


Each shell interaction step: 1 HTTP request with a typical payload of 20 KB.


Each interaction step: 1 ABAP session with a lifetime of 15 seconds and main memory consumption of approximately 3 MB.

Conclusion : The HTML shell creates a continuous but low-performance footprint on both network and server.

Content Area

NWBC does not change the performance profile of the contained content or of applications.

As to the SAP GUI content, NWBC starts a normal SAP GUI to run any specific transaction. NWBC does have a higher overhead to start the SAP GUI content and start the transaction inside the new SAP GUI content area. However, once the SAP GUI content is running, we have a normal SAP GUI running with the transaction, giving exactly the same performance footprint as when the transaction is running standalone.

Similarly, when starting any Web Dynpro ABAP application, NWBC hosts a browser control in which the Web Dynpro ABAP application is running. It is exactly the same application running in the same browser as the application running standalone. Again the performance impact of the application in an NWBC content area is similar to that of the application running standalone.

Side Panels

Similar to applications running in the content area, NWBC itself does not change the performance profile of any application running in a side panel. The same performance aspects apply to an application running in the content area as an application (or the same application) running in a side panel. However, what is important is that the side panel hosts the application as a completely separate instance running into a separate server session. For example, if a specific transaction is running in the main content area with an application based on Web Dynpro ABAP in the side panel, two server sessions are open in parallel: one for the SAP GUI transaction running in the content area and one for the Web Dynpro ABAP application running in the side panel. As such, the performance footprint of such a scenario is effectively the sum of the resources used for the transaction and that of the side panel application.