Skip to Content
Author's profile photo Poovin Kumar V

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.


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 :

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Great article! I guess the one question is if you have HANA, why is the dashboard server itself having to process data?

      I am curious what a very large data set would be for Design Studio to process?

      Quite impressive how much performance you were able to squeeze with tuning.

      Author's profile photo Michael Howles
      Michael Howles

      I think it is a performance hit for use of MDAS, I'd imagine, regardless if the Data Source is BW, HANA, or UNX.  I don't see in the stats what type of datasource it was for sure, only that it was a BO Deployment of the runtime.

      Author's profile photo Poovin Kumar V
      Poovin Kumar V
      Blog Post Author

      Hi Michael,

      I was using Enterprise HANA as the datasource for this example. I was focusing on the processing time and hence did'nt show the Data_Source stats..

      Author's profile photo Poovin Kumar V
      Poovin Kumar V
      Blog Post Author

      Hi Ryan,

      Good Question!..

      In BOBJ platform, eventhough the datasource is HANA, only the computation and processing of data happens at the HANA layer. Other processing for the Dashboard happen at BOBJ layer.

      In HANA platform, Both data processing and dashboard processing happen within the HANA server.

      Large dataset refers to data with 300k - 400k cells. When many End-users frequently access such datasets, there will be performance lag if the server is not perfectly sized

      In such cases, sizing will help to improve performance