SAP Analytics Cloud
Page tree
Skip to end of metadata
Go to start of metadata

Motivation

Parallel Processing

Having multiple widgets in a story with long running queries did cause extensive BW processing time. The reason being that by default BW can only do sequential processing inside one session.  

Parallel processing enables parallel query processing inside BW by creating multiple sessions, which then can be processed simultaneously. (On leaving the story or closing the browser tab these extra sessions will also be closed). This setting allows you to set the number of additional, parallel HTTP sessions used for executing SAP BW queries. By default, all SAP BW queries are executed in sequence, in a single session. Executing the queries in parallel sessions can improve performance.

HTTP/2

HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP protocol used by the World Wide Web.  HTTP/2 reuses the HTTP1.1 (methods, status codes, semantics etc.) but focuses on end-user perceived performance by optimizing network and server resource usage.

With HTTP/1.1 Chrome and other current browsers mostly allow between 6-8 open connections to a single host (Chrome itself allows for exactly 6 connections). If all connections are used and new requests were to be triggered from Orca side, these requested would be stalled. That means they are planned, but their execution is delayed until a connection becomes open again. So time is lost at this point.

Be aware that all browser vendors support HTTP/2 exclusively over HTTPS

Enablement 

The Feature is only active when a customer actively sets a higher number in System -> Administration -Number of Parallel Sessions opened for BW Data Sources

Analysis

HTTP/2

As can be seen in the below screen, since the browser is limiting the number of connection to 6 with HTTP/1.1, the HTTPS calls after the first 6 are stalled, until one of the already fired calls finished. While with HTTP/2 the number of possible opened sessions, which are running parallel, are increased to 12. 

Parallel Processing

Having three widgets with the same queries without parallel processing takes roughly processing time for one query * 3, while with parallel queries enabled, we observed a performance gain of well over ~110%.


Without Parallel Processing


With Parallel Processing

Resource Consideration

Memory Usage

It is important to know that each parallel sessions, opened by the Browser is having an 1:1 relation with an ABAP application sessions (transaction SM04, or transaction AL08 (for all application servers)) on the backend side. Each ABAP application sessions is having memory usage, depending on running active work processes in the session. The memory consumption of the ABAP work process depends on the memory, used by a Query execution. Therefore it is needed to consider, the more Queries run in parallel in different ABAP application sessions, the more memory is needed to be allocated. To sum it up, more Number of Parallel Sessions opened for BW Data Sources configured in SAC, more load is needed to be handled by the BW backend. For more information please the following wikis:

In order to avoid possible memory issues inside one ABAP session, the following NOTEs also needed to be implemented:

Number of ABAP Work Process

The more Queries run in parallel, the more ABAP work process will be in use. When an application server is running, there may be times when all work processes are busy. The situation may arise where a work process needs a further work process in order to process its request.

rdisp/wp_max_no parameter value defines the maximum number of work processes that Application Server ABAP (AS ABAP) can start. 

rdisp/wp_no_dia parameter defines the number of dialog work processes on an AS instance

For more information please check the official documentation.

Maximum number of opened connections at one time

Maximum number of (concurrently) open connections of the ICM or SAP Web Dispatcher. The parameter value can be greater than icm/max_threads, since inactive connections do not require a thread in the ICM. The maximum number of sockets that one process can open is restricted by the parameter icm/max_sockets and ultimately by the operating system. This also therefore restricts the value of icm/max_conn.

The number of opened connections can be checked in transaction SMICM -> Goto  -> Connections  -> Display connections

Timeout Parameter Configuration

About the recommended timeout parameters, please check the following wiki page.



  • No labels