Why Sizing matters for SAP Design Studio Performance

A very common complaint about SAP Design Studio applications is poor performance. After detailed analysis of such issues, we realized that a lot of it has to do with inadequate server sizing and performance tuning. Even with a perfectly sized SAP BusinessObjects server that can effectively handle WebI, SAP Crystal Reports and SAP Dashboards, SAP Design Studio might not perform as good because certain implementation strategies have to be applied specifically for it. Also, implementing SAP Design Studio on top of an existing SAP BOBJ landscape may also pose challenges and due care has to be taken in such cases.

Data Trend

Data grows exponentially in most production systems. Data growth is also influenced by increasing digitalization and the need for analytics on huge volumes of historical data. To deal with this, backend servers have gone through tremendous changes in architecture, resource utilization and performance over the past few decades. Though similar changes have taken place in visualization systems, they have not completely complimented the growth in backend systems.

Data growth trend

BI Landscape – Resource Allocation

As data storage / management / processing technologies have grown to great heights with newer architecture and algorithms, they run on complex servers with sufficient resources. So, handling voluminous data has become easier. However, front-end servers typically run on limited resources.

The image above is typically how resource is allocated, in many landscapes, and shows that it is lopsided. We do not imply that frontend systems should be allocated TBs of RAM, but at least it should be reasonable, based on usage. It is a good idea to adhere to SAP’s best practices and recommendations to get the most out of analytical tools.

Technically speaking, SAP Design Studio architecture is good – it pushes all calculations to the back-end and renders as HTML pages. So performance is generally good compared to other applications. However, when huge data sources are processed or the system is heavily used, applications take a huge hit in performance and this is where the strategies below will help.

Design Studio – Sizing and Best Practices

Scale Out

If your SAP BusinessObjects platform is split across multiple nodes, scale out your SAP Design Studio implementation across multiple nodes. Increased number of nodes to process SAP Design Studio requests will improve user experience.

Dedicated Servers

Provide dedicated APS servers for analysis applications. Hosting SAP Design Studio in APS servers that also cater to other applications, will reduce performance.

Data Access

SAP Design Studio makes use of universes, BW Cubes and HANA connections. Ensure that correct resource allocations are done to the semantic layers.

Memory Allocation

Calculate resource usage based on the number of users and components used in your applications. SAP note 0001177020 has more information about sizing.

Client Sessions

Estimate the number of end users who will be accessing the server and decide on the max no of concurrent client sessions accordingly. If user count exceeds max concurrent client sessions, users  will experience performance lag. Add a processing server or resize existing APS to accommodate new users.

JAVA Script Compression

Make use of compression mechanisms supported by the platform to reduce application transfer size. This will ensure smooth performance and reduce time lag in content transfer to client. Please take a look at my blog on JS compression for more on this.

Sizing is not a one-time thing. Usage statistics have to be constantly tracked and processing servers resized accordingly.

Benchmarking

We did some benchmarking to prove that sizing improves performance. For this, we used a simple application with a single data source that renders data in a crosstab. Two SAP BOBJ servers, connected to the same back-end system were used, one was sized for effective performance and the other was sized for basic operations. On executing the application, there was a difference of 2327 ms for data / back-end operations and 153 ms for rendering.

Since there was a difference of more than 2000 ms for a simple, single data source dashboard, it is obvious that the difference will be enormous for complex applications with multiple huge data sources. This clearly shows that sizing is critical. Shown below are images of the statistics.

Profiling on optimized server – Processing Stats

Profiling on non-optimized server – Processing Stats 

Profiling on optimized server – Rendering Stats

Profiling on non-optimized server – Rendering Stats

source : http://visualbi.com/blogs/design-studio/sizing-matters-sap-design-studio-performance/