This article is the final one in a series about OBIEE and performance. You can find the previous posts here: 1. Introduction [/2013/03/performance-and-obiee-introduction] 2. Test - Define [/2013/03/performance-and-obiee-test-define] 3. Test - Design [/2013/03/performance-and-obiee-test-design] 4. Test - Build [/2013/03/performance-and-obiee-test-build] 5. Execute [/2013/03/

Potato potato? When I first drafted this blog post, I gave it the title “Tuning”, rather than “Optimising”. Tuning is the word used so often in the context of performance, but it can actually be a bit misleading. A system that has fundamental design flaws doesn’t need “tuning” -

This part of the OBIEE performance cycle is the one which arguably matters most. Having defined what we’re going to test, built a means by which to test it, and executed that test, we now need to sift through the tealeaves and work out what the data we collected

Having designed [https://www.rittmanmead.com/blog/2013/03/performance-and-obiee-test-design] and built [https://www.rittmanmead.com/blog/2013/03/performance-and-obiee-test-build] our tests, we now move on to looking at the real nitty-gritty - how we run them and collect data. The data that we collect is absolutely crucial in getting

Performance matters. Performance really matters. And performance can actually be easy, but it takes some thinking about. It can't be brute-forced, or learnt by rote, or solved in a list of Best Practices, Silver Bullets and fairy dust. The problem with performance is that it is too easy

This article is the fourth in a series about performance and OBIEE. In previously articles I described how test design should be approached, and in this article I explain in detail how to use some of the tools available to build the tests. JMeter JMeter is open-source software maintained by