OBIEE Tuning - Under the hood

 Monitoring what to tune:

• Monitor performance using Enterprise Manager,
• OBIEE Admin/Session tool
• Usage Tracking
• Fiddler browser based client developer add-on's - see where is most of the time being taken for a page load and plan accordingly.
• Use Oracle Application Testing Suite (OATS) for Load Testing using a test strategy reflecting the load and type of usage.

Understanding Monitoring is very important  because Oracle's documentation is not very clear on how the settings effect the overall performance. They at best provide two values - default, and suggested, without much explanation. So if we want to customize these for the situation at hand, we should be able to monitor the effects of changes and tweak it to the what best applies to our situation.

Apply latest patches

• Upgrade to the latest patch set - follow Support documentation (Upgrade advisory) to plan major upgrades.
• Stay on approved Java version

Delegate work away from OBIEE server

Reverse Proxy/OHS Cache: OBIEE prevents the browsers from caching its content. This is a desired tract to ensure fresh reports data, but overloads the BI Presentation server/OHS as all the static content now needs to be served for each and every request.

This can be mitigated by implementing a Reverse Proxy server or enabling caching on Web server.

Optimized connections

The Connection Pools to the underlying databases should be enough to be able to reasonably service the expected number of concurrent users. Pools also exists for network connection and here, the timeout should be reduced so that they can be freed more often and made available for subsequent calls. There are various parameter based on the underlying OS to achieve this:

• Database Connection Pools for these should be reviewed:
• Database connection in the physical layer:
• Init-Block Connection Pools
• Physical DB Connection Pools
• BIP/MDS Connection Pools (others if Essbase/ODI are installed)
• Inter-Process connection pool:increase the bridge connection pool for Presentation server to sufficient level
• Enable compression at web server to ensure high throughput
• Ensure sufficient search depth within the AD of choice. This can be result in additional complexity if there is a cyclic membership.

Thread Management

•     Manage Stuck thread trigger time: 
• Account for long running queries from the usage tracking parameters 
• Ensure that the system doesn't flag threads as stuck in that time frame.  
•     Increase thread pool for charting engine, job manager

Turn Off Debugging features on production:

•     Log levels
•     Wrap Data Type (JDBC)
•     Lock down production RPD to read only mode
•     Database client libraries - disable signal handling

JVM - Memory

• Increase Heap
• Compressed Reference
• Thread Local sizes based on available physical memory for OBIEE

Cache management:

• Move cache and temp directories(javaHost/BIP/BIPS) to RAM disk (~256 GB)
• Use cache seeding. Automate using SASeedQuery after ETL process.
• Adjust maximum cache size based on frequently used/first page reports
• Increase number of open files limit in OS to allow for multiple concurrent processing of cache/sort/logs etc.

Aggregate data

Reduce Database's processing cycles, and the network bandwidth needs.

Hardware Optimization

• Maximize Memory and Networking capability of each server. 
• OBIEE licensing is core based. Addition servers will result in added licensing cost. So maximize the memory and network capacity on the serve before scaling out.
• Throw in more hardware, vertically scale the system for performance, get high availability as an added benefit.

Sizing of Server

Factors used to determine the capacity of a server:

•     Total Named user vs Concurrent users
•     SSL turned on or not.
•     complexity of the Report formats
•     Underlying database and the connection between the two servers

BI Publisher

•     Ensure appropriate JDK/JVM
•     Optimal memory and disk space allocation
•     Use BI Publisher's XSLT processor (Enable scalable feature of XSLT processor)
•     Divide optimization efforts by
• Online/Concurrent Usage
• Report size - Small(~10 Pages)/Medium(~50 Pages)/Large(> 100 pages)/ Extremely large (> 100,000 rows)
• Bursting - Total number of report vs. time window
•     Run-time optimization
• Enable XSLT Processor, enable scalable features
• Enable Muti-Threading
• Increase Thread Count
• Increase FO Buffer size
• Increase Pages in Caches setting
• Enable Run-Time Cache
• Disable Autorun
•     Use JNDI over JDBC
•     Push database functions like Joins to Database (Use OBIEE models)
•     XML
• Use short names (smaller overall XML)
• Use Unique names across structures
• Avoid XML attributes
• Use Absolute paths for Searches rather than Relative paths
•      Scale out
•     Configure debug settings to minimal for production

Finally some functional optimization

• Rearrange dashboards so that the smaller/faster reports are rendered first
• Show summary reports (from aggregates) first
• Force users to put appropriate filters in prompts
• Partition database
• Index appropriately
• Run Statistics and keep them current

Moniter, Adjust, Repeat!

Sachin
Architect - Oracle Engineered Systems
Exalytics/Exalogic/Exadata
BuzzClan LLC

BuzzClan is a business consulting company collaborating to provide Oracle software advisory services & implementation services. BuzzClan LLC is committed to providing substantive business value on each and every client engagement. We do this through a combination of industry-specific business expertise, technical skills, proven project management methods and our “onsite - off site - offshore” delivery model. We strive to work in partnership with our customers to build high-performance teams and create business solutions that will last.