- Tips for Optimizing the Performance of Web Intelligence Documents
- Document History
- Introduction
- Chapter 1 - Client Side Performance
- TIP 1.1 - Use HTML Interface for Faster viewing/refreshing of Reports
- TIP 1.2 - Upgrade to BI 4.1 SP03+ for single JAR file Applet Interface
- TIP 1.3 - Ensure Online Certificate Revocation Checks aren't slowing down your Applet Interface
- TIP 1.4 - Make sure JRE Client Side Caching is working
- TIP 1.5 - Ensure you are not running into these known JRE Security Change issues
- TIP 1.6 - Choose the right client - Webi Rich Client vs HTML vs Applet Interfaces
- Chapter 2 - Process Best Practices
- Chapter 3 - Report Design Best Practices
- Chapter 4 - Semantic Layer Best Practices
- Chapter 5 - Formula & Calculation Engine Tips
- Chapter 6 - Sizing for Performance
- Chapter 7 - Architectural Differences between XI 3.1 & BI 4.x
- Chapter 8 - Performance Based Improvements / Enhancements
Tips for Optimizing the Performance of Web Intelligence Documents
DRAFT DISCLAIMER - This document is a work in progress and will be released 1 chapter at a time. Please follow or subscribe to updates to ensure you are notified of the latest changes.
Document History
| Date | Who | What |
|---|---|---|
| 10-01-2014 | Jonathan Brown | Created Initial Document Structure and Completed Chapter 1 - Client Side Performance |
| 10-02-2014 | Jonathan Brown | Made some minor updates to the formatting and some links |
| 10-08-2014 | Jonathan Brown | Started on Chapter 2 - Process Best Practices Started on Chapter 2 - Process Best Practices |
Introduction
This document will become a central repository for all things Web Intelligence & Performance related. It is a living document and will be growing over time as new tips, tricks and best practices are discovered. We encourage suggestions and contradictions on the content within and hope the community will collaborate on this content to ensure accuracy.
I am the writer of this document but information contained within is a collection of tips from many sources. The bulk of the material was gathered from within SAP Product Support and from the SAP Products & Innovation / Development teams. Some of the content also came from shared knowledge on the SAP Community Network and other like websites.
The purpose of this document is really to bring awareness to known issues, solutions, and best practices in hopes of increasing the throughput of existing hardware, improving the end user/consumers experience, and to save time and money on report design/consumption.
Chapter 1 - Client Side Performance
Client side performance tips and tricks cover anything that is specific to the client machine. This includes the HTML, Applet and Rich Client Interfaces as well as the Browser that the client uses to a certain degree.
TIP 1.1 - Use HTML Interface for Faster viewing/refreshing of Reports
The HTML Interface is a light-weight thin client viewer. It uses HTML to display and edit the Webi Documents. Since it is a thin client application that requires little more than displaying and consuming HTML, it is a great choice for those users that want fast document viewing and refreshing in their browser.
The HTML Interface does have a few less features in comparison with the Applet Interface and you will have to weigh the benefits of performance vs functionality.
Chapter 1.4 of the Webi User Guide covers the differences between the HTML, Applet and Rich Client Interfaces. Review this to help you make a decision whether or not the HTML Interface will do everything you need it to do.
Here is a screenshot example of what the feature comparison matrix looks like in the user guide
Below is a link to our Web Intelligence documentation page on our Support Portal. Go to the End User Guides section to find the latest Webi User Guide documentation.
Here is also a direct link to the BI 4.1 SP04 (most current at time of this writing)
TIP 1.2 - Upgrade to BI 4.1 SP03+ for single JAR file Applet Interface
BI 4.x introduced a new architecture for the Applet Interface, aka Java Report Panel/Java Viewer. Previous versions were a single JAR file called ThinCadenza.jar.
BI 4.0 and earlier versions of BI 4.1 split this architecture out into over 60 jar files. This was done for ease of maintenance and deployment originally but Java updates later made this architecture more cumbersome. Java security updates and restrictions that are now enforced by default have made the performance of this new architecture too slow in many cases.
BI 4.1 SP03 and above have reverted back to a single .jar file deployment. This will often improve performance on the client side due to a reduced number of security and validation checks that have to happen on each .jar file.
The below What's New Guide talks about this change briefly. It should mostly be invisible to the end users though. Except for maybe the improved performance.
This KBA also covers this issue in a limited fashion:
TIP 1.3 - Ensure Online Certificate Revocation Checks aren't slowing down your Applet Interface
Online Certificate Revocation Checks are turned on my default in newer versions of the Java Runtime Engine (JRE). These basically tell the client side JRE to go out to online servers to validate the certificates that the applet jar files are signed with. On slower networks, this can add a lot of overhead.
Older versions of the JRE did not have this enabled by default so it wasn't an issue.
Since BI 4.x had 60+ jar files to load for the Applet, it could potentially take much longer to run these checks across 60+ files. On slower internet connections, this could equate to several minutes of delays!
I talk about this in much more detail in the following Wiki and KBA:
TIP 1.4 - Make sure JRE Client Side Caching is working
When troubleshooting client side JRE performance issues, one of the first things you want to check is that JRE Caching is enabled and WORKING. We have seen issues with performance when caching was either disabled, configured incorrectly, or was just not working because of some sort of system or deployment issue.
One example is on a Citrix deployment. Since each user can potentially have a unique and dynamic "Users" folder, the cache may not be persistent across sessions. Setting the cache to a common location that can be persistent across sessions may help in this type of scenario.
We cover a lot more on how to enable and validate JRE cache in my Wiki below
TIP 1.5 - Ensure you are not running into these known JRE Security Change issues
A number of Java security updates and changes have caused issues with the Applet Interface. The known issues are well documented and can be found on this Wiki:
This is divided into individual sections for the known issues on different XI 3.1 and BI 4.x versions.
While these are not technically performance issues, they will slow down your end users and will cause delays in viewing, modifying and refreshing documents and instances.
SAP only releases Patches/Support Packs every few months so when Oracle security changes come into play, there can sometimes be a bit of a delay before we can have a patch out to resolve/address the change. Keep this in mind when pushing the latest and greatest Oracle JRE updates out to your clients.
TIP 1.6 - Choose the right client - Webi Rich Client vs HTML vs Applet Interfaces
Each of the Interfaces has a list of pros and cons. Choosing the right client interface for Web Intelligence is about striking a balance between functionality, performance and convenience.
Chapter 1.4 of the Webi User Guide covers the differences between the interfaces. Reading and understanding this should help you decide which interface to use. It's often not as cut and dry and standardizing on only one interface though. Some users may like the HTML interface for viewing of documents but prefer the Rich Client Interface for creating and editing documents. It is really up to the user which interface they use.
Use the Portal link below to find the latest Webi User Guide. Chapter 1.4 covers the interface differences.
Here is also a direct link to the BI 4.1 SP04 (most current at time of this writing)
As a general guideline, we recommend the following use cases for the interfaces:
Webi HTML Interface
- Best interface for report consumers who will mostly be running predesigned reports and doing only light modifications
- The HTML interface utilizes the 64-bit backend servers but lacks some of the design capabilities of the Applet Interface
Webi Applet Interface
- Best interface for report designers and power users who will be creating, modifying and doing advanced analysis of documents and data.
- This interface takes advantage of 64-bit backend servers and can generally handle larger amounts of data/calculations as it utilizes backend servers to do the heavy lifting.
- Since this is a Web Application, timeouts can occur when leaving the session idle or when carrying out long running actions.
Webi Rich Client Interface
- This stateless interface has almost all of the features and functionality that the Applet interface does plus a few additional features of its own. This should be used by advanced designers and power users that wish to have a stable design environment for larger documents
- Can be used with local data sources and some desktop type data sources such as Excel and Access
- Also can be used in 3-tier mode which takes advantage of backend servers for data retrieval
Chapter 2 - Process Best Practices
When we talk about "Process" Best Practices, we are really talking about the workflows around how we utilize Web Intelligence reports in our Business Processes.
This chapter will cover a number of Best Practices that will allow you to build good business processes or workflows around your Web Intelligence documents
Let's get started!
TIP 2.1 - Schedule reports to save time and resources
This may seem like a no-brainer but we see countless support incidents come through that could be avoided with a simple process around when to schedule a document vs view it on-demand.
The Best Practices threshold for Scheduling is 5 minutes. If a report takes more than 5 minutes to refresh and render, then that report should be scheduled.
Scheduling allows for a user or administrator to offload the processing of a document to a backend server so they are not forced to sit and wait for the report to finally come up on their screen.
Benefits of Scheduling Documents
- Provides lower user wait times when implemented correctly
- Allows us to offload processing to non-peak times
- Can help reduce sizing requirements for concurrent users
- Reduces impact on Database during Peak times
- Can combine Instances with Report Linking to produce smaller, faster documents
Studies have shown that in today's world, end users are unlikely to wait for more than 5 seconds for a video to load. For example, if you are on YouTube and click the Play button, would you wait 5 minutes for that video to load up and start playing? I think most of us would give up or try to refresh the video again after about 10-20 seconds.
This holds true for Web Application users too. If a report doesn't view within a minute or two, the consumer is very likely to close the request and try again, or just give up all together. The danger in them submitting the request again is that they are using up even more resources on the backend servers when they do this. Here's a workflow as an example:
- UserA logins to BI Launchpad and navigates to the "Monster Finance Report" document
- UserA Views this document and clicks the refresh button to get the latest data
- After about 2 minutes, UserA is not sure what is going on. The report appears to be refreshing still, but given the fact that UserA is impatient, he suspects that the refresh has "hung" and closes the viewer.
- UserA decides to test his luck and submit the request again. This essentially creates a new request for the same data and potentially works against BOTH requests as they compete for resources on the BI servers and the database side.
- After a few more minutes, UserA gives up and moves on. Meanwhile he has no idea the amount of resources and time he's wasted in the background.
In the above scenario a few bad things happened:
- UserA Never got his report and had a bad experience
- Backend resources were wasted without any usable results
Both of these could have been avoided by building processes around proper use of scheduling.
Here are some tips on how to best utilize scheduling:
- Educate your users to schedule anything that takes over 5 minutes to run
- Encourage users to Schedule reports that they know they will need throughout the day to non-peak hours before their day begins
- Schedule Documents to formats that you know your end users will want such as Excel, Text, or PDF. This can save time and resources during the day
- Utilize Publications when multiple users have different requirements for the same documents
For more information on Scheduling Objects and Publications, see the below links
DOC - BI 4.1 SP4 BI Launchpad User Guide - Chapter 7 - Scheduling Objects
DOC - BI 4.1 SP4 BI Launchpad User Guide - Chapter 10-11 - Publications
TIP 2.2 - Use the Retry options when Scheduling to Automate Retries
Although this isn't really a true performance tip, I do find that it is a best practice that goes hand in hand with scheduling. It often amazes me how many people are not aware of the Retry functionality within the Schedule (CMC Only) Dialog. This feature allows you to configure your scheduled instances to retry X number of times and after X number of seconds if a failure occurs.
Here is a screenshot of this option in BI 4.1
Where this tip DOES save you time is in hunting down and manually rescheduling reports that may have failed due to database issues or resource issues on the BI Platform side. Intermittent failures are usually tied to resources somewhere in the process flow so simply setting up retries a few minutes apart can help in limiting the number of true failures we see in a busy environment.
This option can be set in the Default Settings/Recurrence section of the Schedule Dialog or under the Schedule/Recurrence section. The difference between the two is that the Default Settings option will set the default retry values for any future schedules. Setting it under the Schedule section only sets it for that particular schedule.
NOTE: It is important to note that this option is only available in the CMC and not through BI Launchpad currently
TIP 2.3 - Use Instance Limits to help reduce the # of Instances in your environment
This is another little known feature that you can use to help improve the performance of your system. The feature is called Instance Limits and you can set it on a Folder or Object Level.
The basic concept is that you can set limits on the # of instances a folder or object will keep. If the limit is exceeded, the CMS will clean up the oldest instances to help reduce the amount of metadata and resources that is stored in the CMS database and on the Filestore disk.
Here are the basic instructions on how to enable and set limits, as found in the CMC Help guide:
Setting limits enables you to automatically delete report instances in the BI platform. The limits you set on a folder affect all objects in the folder.
At the folder level, you can set limits for:
- The number of instances for each object, user, or user group
- The number of days that instances are retained for a user or a group
Steps to enable Instance Limits in the CMC
- Go to the Folders management area of the CMC.
- Locate and select the folder for which to set limits, and select Actions/Limits.
- In the Limits dialog box, select the Delete excess instances when there are more than N instances of an object check box, and enter the maximum number of instances per object the folder can contain before instances are deleted in the box. The default value is 100.
- Click Update.
- To limit the number of instances per user or group, Click the Add button beside Delete excess instances for the following users/groups option.
- Select a user or a group, click> to add the user or group to the Selected users/groups list, and click OK.
- For each user or group you added in step 6, in the Maximum instance count per object per user box, type the maximum number of instances you want to appear in the BI platform. The default value is 100.
- To limit the age of instances per user or group, click Add beside the Delete instances after N days for the following users/groups option.
- Select a user or a group, click> to add the user or group to the Selected users/groups list, and click OK.
- For each user or group you added in step 9, in the Maximum instance age in days box, type the maximum age for instances before they are removed from the BI platform. The default value is 100.
- Click Update.
Below is a screenshot of the dialog for your reference
Once you have enabled Instance Limits, you will have better control over the size of your CMS and Input/Output FRS. A bloated CMS database and Filestore can definitely contribute to a slower running BI system in general so having a handle on this can definitely help keep your system running at top speed.
TIP 2.4 - Platform Search Tweaking for Performance
COMING SOON - FOLLOW DOC FOR UPDATES
Chapter 3 - Report Design Best Practices
COMING SOON - FOLLOW DOC FOR UPDATES
Chapter 4 - Semantic Layer Best Practices
COMING SOON - FOLLOW DOC FOR UPDATES
Chapter 5 - Formula & Calculation Engine Tips
COMING SOON - FOLLOW DOC FOR UPDATES
Chapter 6 - Sizing for Performance
COMING SOON - FOLLOW DOC FOR UPDATES
Chapter 7 - Architectural Differences between XI 3.1 & BI 4.x
COMING SOON - FOLLOW DOC FOR UPDATES
Chapter 8 - Performance Based Improvements / Enhancements
COMING SOON - FOLLOW DOC FOR UPDATES