Previously, I detailed an initial foray into sizing a BusinessObjects environment – Squeezing the BusinessObjects sizing model until it bursts, hitting a few bumps in the road where the limits of the model were reached. This time, I’m looking at the same exercise in a different way: how to translate the results into recommendations, considering uncertainties in the assumptions and algorithms. For the moment, we’ll ignore the sage advice from Ingo Hilgefort to go get even more sage advice and assume the crunched numbers said we’ll need to provision 50,000 SAPs.
If we use the built-in suggestion that one CPU core can deliver 2,000 SAPs, that works out to 25 cores. Of course, the values almost never come out exactly divisible by 2,000, and we’ll see something like 24.86 cores, or 25.1, and we’d typically “round up.” The immediate question to that is – how much to round up? To answer that question, we’ll need to speculate even further than how many active users will be online the day the system is available, to how many active users we’re going to expect during the life of the platform. If our needs double, and that could happen, we should have provisioned 100,000 SAPs, or 50 cores. Here’s where your knowledge of the project, and of hardware capabilities, comes into play. For this example, we’ll decide that 60,000 SAPs will cover our needs for the foreseeable future, meaning 30 cores.
With a relatively hard number like 30 cores, you could talk to the hardware vendors (or cloud vendors, but that’s another blog post entirely) and ask how many machines are required to supply that amount of power. And the simple answer might be, oh, we have a 32-way machine that meets that specification. That could get expensive, so looking at 4 machines that have 8 cores each might be feasible, giving a bit of redundancy in case of outages.
Before talking to the vendors, it’s wise to do your own research, preparing for the alternatives that may be presented. You might even have a strategy for specific vendors, makes and models, where staying with one brand or form factor simplifies maintenance, standardizes power and cooling, and gets a volume discount. On sheer computing power, what you should quickly learn is that 2,000 SAPs per core is another simplification. You might get by using that value, but you could end up under or over your needs.
All the certified SAPs values are on the page SAP SD Standard Application Benchmark Results, Two-Tier Internet Configuration, from way back up until right now. There’s even a handy “Download in tab-delimited text format” button, in addition to column headings one can sort on. Be careful dragging that download into a spreadsheet directly for further analysis – many of the lines have wrapped, causing orphaned text (at least the last few times I’ve grabbed it).
For now, I’m only considering results achieved in the last couple years. If I had spare machines around, and this was a pilot project, I might need to consider looking at that inventory. You could filter on specific hardware vendors, platforms, or other criteria, to better understand the viable options. What should quickly surface is the revelation that 2,000 SAPs per core is a decent representation of current hardware designs, but it’s a very rough assumption that can get you into trouble. In the chart below, I’ve done a scatter plot where I divided the published total SAPs by the published cores in the certification results.
SAPS PER CORE – APRIL 2013
Yes, the numbers cluster around 2,000. Or so. But the range goes from close to 500 to nearly 3,500. The trend line points upward, implying that if you wait, you’ll get even more power per core. But you can’t wait, of course. The system needs to be ready yesterday.
Now what? After you document your assumptions, confidence factors, and future plans, you’ll be better prepared to work with the hardware vendors and get the blinking lights switched on.
Thanks again to Greg Myers for helping me vet some of my assumptions.
p.s. Don’t forget non-production, and high availability, and mergers, and acquisitions. And project scope creep.