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.
Some comments on your test @ Ask Tom:
well, they do explicitly state that they didn’t read the entire thing which I found sort of strange — you supposed to read something before going to comment on it. I leaved my comment to clarify some confusions.
[…] some of you probably already noticed, there was a thread on AskTom discussing the scalability tests I did back in 2007. You are welcome to read the entire thread, but in a nutshell, Tom Kyte claimed […]
[…] upshot is that it’s a cool new feature and the problem with the single latch in 11GR1 appears to be solved, but it needs to be heavily load tested before trying it in a production […]