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

Having defined our test, we can now design it. Wordplay? Not really. Regardless of how we run our tests, we’ve got to define up front what it is we are testing. Once we’ve got that, we can then work out how to actually create a test that simulates

Take the first tentative steps along the yellow brick road of investigating performance and OBIEE with this jump into the nitty gritty of how we should define a performance test. An overview of defining a performance test The first step in assessing the performance of OBIEE is defining the test