Posted by Alex Fatkulin on Nov 27, 2007
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 processes |
Buffer Cache |
% linear |
Result Cache |
% linear |
| 1 |
15085 |
100% |
15451 |
100% |
| 2 |
26745 |
88.65% |
28881 |
93.46% |
| 3 |
39144 |
86.5% |
40628 |
87.65% |
| 4 |
52342 |
86.75% |
52625 |
85.15% |
| 5 |
63922 |
84.75% |
62767 |
81.25% |
| 6 |
76336 |
84.34% |
69549 |
75.02% |
| 7 |
88844 |
84.14% |
74208 |
68.61% |
| 8 |
100959 |
83.66% |
76768 |
62.11% |
I made a nice-looking graph from this:
Read the rest of this entry . . .
Posted by Alex Fatkulin on Nov 12, 2007
In my previous blog entry, I explained why I would expect Result Cache not to scale well. Unfortunately, at the time that blog entry was written, I had no access to hardware with more than two cores. That left me in an everything-but-the-proof state. “Theory without practice is sterile.” ©Albert Einstein.
Since then, I got a chance to re-run my test cases on a quad-core CPU, moving one step forward.
I re-executed my test cases with one to four processes against the Buffer Cache and the Result Cache in order to capture the number of lookups per second. I raised number of iterations to 1M to make the results more stable though.
Here is what I got: Read the rest of this entry . . .
Posted by Alex Fatkulin on Sep 13, 2007
In the previous article, I described my observations of RC Enqueue. Now it is time to take a look at the RC latches.
Latches, being serialization devices, are scalability inhibitors. Not that they inherently prevent you from scaling, quite the opposite is true. Serialization is a must if you expect your system to produce anything apart from GIGO (Garbage In Garbage Out). Concurrency is essentially made possible through serialization of shared resources. That being said, I would expect Result Cache to beat Oracle’s buffer cache on read-only workloads, since that is what RC was designed for. That is, Result Cache should perform faster and scale better.
Read the rest of this entry . . .
