SAP BusinessObjects (BO) BI 4 Platform has come with many improvements that have made the system more complex. We, as BI 4 administrators, are required to know how this application works in order to apply the proper optimization improvements to the platform, when it is required. In this blog article, we will cover the most important concepts that need to be considered as a first step to increase the performance of the BI platform.It is very important for a good designer to understand the conceptual tiers in the BI Platform: Application Tier, Intelligence tier and Processing tier. We will refer to each one of them and we will nail down some optimization tips.
Optimizing Application tier (web tier)
BI 4 is set with the Tomcat 7 web application whose server component has a built-in http that also allows to process static content; however, a dedicated web server, such as Apache, allows to host static content and therefore balance the web components to be processed.
By adding a standalone Apache web server and using the wdeploy in split mode, we can improve navigation speed 25% or more. This can be done also in the same machine where the tomcat server is located. There is a dedicated article about how to do this and it can be found here: http://scn.sap.com/docs/DOC-6191
On the other hand, Java 7 delivers interesting improvements, such as garbage collector and faster start up for multi-core CPU. Although the use of JAVA 7 seems to be a priority in 4.2 roadmap, in the meantime it is good practice to be generous when increasing tomcat’s memory pool whenever is possible.
Optimization in processing tier
The Adaptive Processing Server (APS) hosts more than 20 services and it is java-based, and the JVM using Java 6. So it is limited in terms of garbage collection, therefore we have needs in terms for system configuration wizard, in order to split the APS into separate containers, making the management of the APS easier. By default, the APS comes as a single instance with all the services and with a maximum java heap of 1GB. This might be good for small development or a demo system, but it is not ideal for a real production system - splitting APS helps troubleshooting & problem containment.
We can duplicate or create new APS in new nodes to increase the power and there are two ways of doing this:
- Clone the existing APS server and remove the services not needed
- Create a new server and add the services needed
Both options are good and it will depend on how reusable the configuration of the APS is, but the result is the same. Although you may have distinct configurations, it is good practice to always have at least one APS with ALL the services included, whether it is stopped/disabled, core services of APS are always needed.
There are many approaches when configuring APS and we could write dozens of articles about it. The best approach is always the one that fits better to the customer’s needs, which tools they have, which sources, etc. The most important is to identify the bottlenecks and make the best design to avoid them.
An SAP article explains in more in detail all these approaches for sizing the APS and can be found in http://scn.sap.com/docs/DOC-31711. For example:
- How to clone APS or how to create and configure a new one.
- Add a dedicated APS for DLS bridge Service to optimize BICS for web intelligence.
- Create a dedicated APS for search index.
- Create a dedicated APS for analysis.
We can summarize some of the best practices as follows:
- It is good practice to split the APS by product.
- About JAVA heap size:
- Setting –xms (initial) and –xmx (maximum) to same value increases predictability.
- Problem: JVM cannot compensate if a bad decision is made.
- Allocating sufficient heap when possible:
- It is the performance factor for BI java based process.
- Starving APS performs poorly as it swaps memory to disk.
- Placing monitoring and auditing services in same APS makes good sense (APS hosts the monitoring service). Historical trending data can be stored in the same database instance. Monitoring is key in identifying bottlenecks and knowing more about the BO performance. An excellent article about how to use monitoring can be found in http://juancaruiz.com/clariba/introduction-to-cmc-monitoring-in-sap-bo4-sp4/
- Search index. After the installation, build scope for Search index gradually. Do not include unnecessary details because it may slow down the performance. So it is good to improve the search index only once you are confident with the system.
- Setting –xms (initial) and –xmx (maximum) to same value increases predictability.
Intelligence Tier
For the BusinessObjects platform, CMS is the brain. CMS Updates meta-data, verifies security and basically interacts with the system database, which is key for the overall performance of the platform. Every operation is impacting the system database, and therefore it could become a bottleneck if it is not well configured.
Key criteria for CMS configuration:
- The connection pool is configurable in the CMC. The default value is 14 but can be set up to 50. The connection pool speeds up connection times between the user and the server. So it is good practice to set this value to 50 whenever is possible
- CMS uses a footprint of 1GB of memory. Each object is around 10kb plus or minus. Check in the CMC the number of objects and consider increasing the value for max objects in cache if possible (this will increase the memory footprint of the CMS).
- Scaling CMS. Generally one CMS expects to have 400 heavy user. In order to balance the load, add a new CMS every 500 users.
- Do not to stack more than 1 CMS in the same physical system.
- Place repository databases (system and audit databases) next to the CMS. CMS is doing many queries to these databases, insert and updates.
Other servers that should be considered are the File Repository Servers: Input file repository server (IFRS), which stores all documents and program objects published in the platform, and the Output File Repository Server (OFRS), which stores all the instances generated by the system. There are some considerations that we can apply to improve the performance of these servers:
- Place the IFRS next to processing servers, so all the requests for a report template don’t need to go around a wide network to find them.
- Limit the number of instances on schedule jobs for optimization of OFRS. Without instance limits, it is possible to have thousands of report instances. This is impacting the OFRS since it increases the complexity of the instances structure, so when a user requests an instance of a report it makes the OFRS slower when trying to find it.