Skip to Content

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

SAPS-per-core-2013-04.png

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.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Charles DiTrani

    My hardware has a SAPS rating of 231,580; this is for a XEON E5-2650 v2 processor (dual socket, 8 cores per processor). That gives a SAPS per core of  ~14,400 assuming 16 cores. That sounds high; am I missing something?

    (0) 
    1. Jim Spath Post author

      Charles:

        How did you determine the SAPs rating for your hardware?  I’ll go out on a limb and speculate your hardware vendor gave you the specs.  It does seem high to me.

        If you look at the published SAPs certifications here, you can sort on the SAPs column by clicking on it (twice, to get the maximum to the top). The highest value published is 844,420 (CERT 2013014) – on a system with 40 processors and 640 cores (Solaris 11/Oracle 11g/Fujitsu Sparc M10-4S). Other systems near the top are from IBM and HP, with their Power and Itanium (Intel) chip sets, respectively, and other Sparc chips from Oracle, Sun or Fujitsu.  The top Windows machine (CERT 2011034) is on page 2, at 140,720 SAPs (64 processsors, 128 cores, 256 threads).

        Maybe someone added up several machines in your environment to get a “grand total”?

      Jim

      (0) 
      1. Charles DiTrani

        Actually it came from one of the SAP spreadsheets. I divided the SAPS rating of 231580 by 16 to arrive at 14473 per core. It seems about 7 times too high.

        It was from the ‘SAP SD Standard Application Benchmark Results’, SD three-tier results. 

        (0) 

Leave a Reply