Oracle 11g Result Cache Tested on Eight-Way Itanium

This will be the final post in my series on Result Caches. In my previous article, I had already got almost everything. Almost — four CPUs (cores) were still not enough to saturate the single latch. As you’ve probably already guessed, today we are going with an eight-way test.

Please note that today’s numbers are different since I’m using an entirely different hardware platform. While the four-way tests were done on a 2.4GHz Core 2 Quad box, today’s eight-way tests were done using four dual core Itanium 2 CPUs running at 1.1GHz.

Let’s take a look at the results:

# of processesBuffer Cache% linearResult Cache% linear

I made a nice-looking graph from this:

The performance drops are quite dramatic. While going from one to two processes can bring us an additional 13430 RC lookups per second, going from seven to eight processes gives us only 2560.

And stats regarding Result Cache: Latch:

# of processesGetsMissesSleepsWait Time

Here’s another pretty graph, this time of Result Cache: Latch wait time:

As you can see from the above figures, it only takes six concurrently-running processes before we start observing major issues regarding the Result Set: Latch contention.