Sizing Your SAP BusinessObjects BI4 Landscape
From the outset, I’m going to argue that although this is numbered Step 6 that this is by far the most important step to get to SAP BusinessObjects BI4. And that step is SIZING. How many eyes just rolled and frustrated moans were uttered? Lots I’ll bet because sizing BI4 is tricky. Here begins the delicate dance between the tech-heads and the bean-counters. Those of us that are techies and do the sizing are nearly always at odds with the folks who have to foot the bill for the new hardware we’re requesting to run BI4 on. “You never use all of the resources you ask for”, “Our deployment just isn’t that big”, “The old one doesn’t use anything like that”, “What did you smoke on the way to work today?”. If I’ve said it once, I’ve said it a thousand times: BI4 is not your Dad’s BOBJ. You must unlearn what you have learned, this is a totally different ballgame (see Eric Vallo’s related article, BI4 Is a Big Baby and Dallas Marks’ related article, SAP Updates Minimum Hardware Requirements for BI4).
The Difference of 64-bit
The biggest change in the need for more resources is the simple fact that BI4 is a 64-bit application. The past few versions were 32-bit, which meant they were more CPU-intensive and each process had a 2GB RAM constraint, because when 32-bit was the new thing on the block, nobody could imagine needing more than 2GB or memory. 64-bit applications are not constrained that way. 64-bit applications can consume darn near as much memory as the system contains if you let it. Does it need THAT much? Probably not, but they need significantly more memory than their 32-bit counterparts. So we see a major shift in thinking here just by this one simple fact. We have moved immediately from a CPU-intensive application to a memory-intensive application. Do not skimp on memory for BI4. Please. You may not use it all on day 1, but you’re going to want it as soon as your system starts being used.
The Adaptive Processing Server and Adaptive Job Servers
While these services are technically included in SAP BusinessObjects XI 3.1, their role has been vastly expanded in BI4. When you install BI4 fresh and sparkly new, the Adaptive Processing Server (APS) and Adaptive Job Server (AJS) are huge “junk-drawer” services. If you read the fine-print in the Admin Guide, you’ll notice that the state the APS and AJS are in when shipped ARE NOT FOR USE IN PRODUCTION. In the early days of BI4, we were left to try and figure out the way to split these bad boys up on our own. If you’re starting today, you’re in luck, because the process has really been documented well now. Head on over to the SAP Community Network (SCN) and grab yourself a copy of this Best Practices for SAPBO BI4 Adaptive Processing Servers. This is your new BFF. Without rehashing the whole document here, I’ll summarize. You’ll basically want to split out nearly every service into its own APS process with a different memory heap size for each, paying special attention to the services that are most important for you and your work flows. The APS is all Java, so you have the ability to set a maximum Java memory heap size for each process, and you should. Follow the guide. Different services have different memory requirements. Now, this guide just covers the APS, but you’ll notice that I spoke about APS and AJS in the beginning here. That’s because it is my firm conviction that you must split up the AJS as well in the same fashion as the APS. Why? Because there are only so many jobs each AJS can handle at one time, and scaling out will increase your scheduling throughput. There is also a limit (a limit from Java, not from a 64-bit perspective) on how much memory you can give to a service before it begins to perform poorly. Having multiple services in their own memory space will get you the gains you need in scheduling capacity without worrying about performance problems because you have a monster heap. Greg says “Split ’em”!
Where Do I Start?
I sat asking myself this same question the first time I tried to size a BI4 system for a customer. I felt like I was looking for a needle in a haystack. But during that process, we hatched a pretty nifty idea, and it ended up being so helpful that we decided to give it away for free to help everyone out. I’m talking about the Sherlock® Quick Sizer. If you have an existing XI 3.1 or XIr2 system and are planning a BI4 system, then SQS is for you with our compliments. SQS will help give you the numbers you need to input into one of the new SAP sizing tools. I recommend you use the SAP BI4 Sizing Estimator tool found on SCN. It’s an Xcelsius dashboard. You run SQS on your existing system, it will output the numbers you need to put into the Sizing Estimator so you can begin to estimate your BI4 hardware needs.
What’s a SAPS?
You’ll notice pretty fast once you open up the SAP BI4 Sizing Estimator dashboard that it is giving you 2 numbers as output; SAPS and RAM. While we’re all familiar with RAM, many (especially those of us who are old and have been with the BOBJ product since the pre-SAP days) are not familiar with what SAPS is. SAPS is a measure of throughput that has been around for quite a long time. It is pretty much a measure of every other facet of hardware performance besides memory. 1 SAPS is roughly equivalent to the horsepower needed to process 1 transaction in an SAP ERP system… I think. In the grand scheme of things, it doesn’t really matter. The Sizing Estimator will tell you how many SAPS you need, and any hardware vendor worth their salt can tell you the SAPS rating of their hardware. The Sizing Estimator also allows you to do a rough conversion from SAPS to CPU cores, which I find pretty darned helpful myself.
Not the Whole Picture
The BI4 Sizing Estimator is not the end of your sizing quest. First, it does not include all of the tools or services required, so there is still a lot of manual sizing you must do in order to paint a more accurate picture. Most notably, the Sizing Estimator Dashboard does not account for sizing of the DSL Bridge Service (an APS service you should DEFINITELY split out on its own). DSL Bridge is used when connecting to BW through BICS and also handles all of the connections that come from the new UNX-formatted universes. The BI4 Sizing Estimator Dashboard also does not include Explorer, so if you’re using that, you’ll need to add in SAPS and Memory for that separately. Those are just a few, there are more. I can’t stress enough that you must, must, must do your homework while sizing. If you aren’t sure, or have concerns, it is money well spent to hire an expert to come and do the sizing for you. SAP has a lot of documentation on a new microsite. Go read up on the Sizing and Deploying SAP BI4 site. Read it all, then read it again.
One Chance to Get it Right
The reason I say over and over that sizing is important is really for a simple reason. When you create a sizing estimate for your organization, people are going to go out shortly afterward and spend company money on buying hardware. Hardware you recommended they buy. If you do not buy big enough, fast enough, beefy enough things are going to get ugly. It becomes awkward very quickly if you spent a whole bunch of money on hardware, install and deploy BI4, only to find out that it performs just slightly faster than the speed that molasses pours in January. Going back to the till to buy more memory or another server so soon will be unpopular. It is critical you get the right amount of the right sized hardware from the outset, because you’re likely going to be stuck with that hardware for a few years (3 is typical). I have personally seen my fair share of undersized BI4 systems that customers are thoroughly unhappy with. If the system can be right-sized, the difference is like night and day.
Sizing up Sizing
Can you complete a sizing exercise by yourself? Certainly. If you have the time to dedicate to educating yourself on the process and are willing to put in the effort, you certainly can. SAP has been really good about getting information out to customers to help them make their decisions. Is there value in hiring some help for sizing? Absolutely. Do we provide sizing services? Yep, we sure do. Sizing your BI4 system properly is arguably the single-most important success factor for your upgrade project. If you build a house on the sand… well you know how the rest of that goes. Make sure you build your BI4 system big and beefy enough to handle what you’re going to throw at it, and it will do right by you. Give BI4 the fighting chance to impress by building it a big-enough stage to perform on. Alright, I’m done with bad metaphors. Questions? Bring on the comments. We’re here for you.
5 thoughts on “10 Steps to SAP BusinessObjects BI4 – Sizing”