The hardest thing in the *world* to do is estimate how much capacity a
piece of Oracle application work will consume (sorry, Mogens, I meant *
planet*). When I was at Oracle, I got these questions all the time: "40 GL
users, 20 AP users, 6,000 vendors, …, the CEO has green eyes: what kind of
system should we buy?"
The real proof of how impossible this can be comes when you can show that
two identical companies with identical application software configured
identically, with identical hardware, identical user counts, and even
identical row counts can have two totally different performance
characteristics. All it takes is one custom report. Or one user who runs 60
aged trial balance reports per day at one site instead of the 6 runs a day
at the other site, to have a profound impact upon performance. Even some
variable like the order in which a table's rows are inserted and deleted can
mess up your on-paper capacity plan beyond recognition.
It's truly the Butterfly Effect. It's unstoppable.
What people do, then, is this: They overbuy their hardware by some "safe"
factor like, say, five (Tom Kyte's famous observation). If you try to
overbuy your hardware by 5X, then your performance won't stink too bad if
you accidentally messed up and actually overbought by only 2X. If you really
did overbuy by 5X, then—what the heck—you'll grow into that capacity
someday, right? (One of my focal messages to the world is that you probably
can't hit all of your business targets by *only* overbuying on hardware…)
What if your problem is that humans haven't invented a machine big enough
to cover you 5X? Then you have to do something a lot more expensive. Like
actually test. Which of course will require that you actually plan out what
you're *really* going to want to do with your application. Which is
expensive as heck. Or you convince yourself that you can save all this
planning and expense by using an Oracle RAC configuration (the Easy
Button™!), which of course is even *more* expensive, because it doesn't
exonerate you from needing to do the planning and testing that you needed to
do in the first place, plus now you have an even more extravagant and
complex system to plan and manage.
There's no easy answer. You have to have some reasonable operational data
before you can create a reasonable capacity plan. When you have *no* data
whatsoever, then make sure that you start with hardware that will easily
scale in the likely direction that your business will need it to scale. And
then carefully manage—at least *measure—*the work that you let people do
on your system.
*Cary** Millsap*
Hotsos Enterprises, Ltd.
http://www.hotsos.com
*Nullius in verba*
Hotsos Symposium 2007 / March 4–8 / Dallas
Visit www.hotsos.com for curriculum and schedule details...
------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Dennis Williams
*Sent:* Tuesday, June 06, 2006 11:30 AM
*To:* ax.mount@xxxxxxxxx
*Cc:* oracle-l@xxxxxxxxxxxxx
*Subject:* Re: Batch process resource estimation?
Alex,
I think this is a classic computer science puzzle. How to estimate the
resources consumed by a program without executing it. Cary Millsap may even
address this issue in his book.
When configuring a new site, often you are in the unenviable position
of having to guesstimate the size of server to purchase and an early stage.
This doesn't meant these are very reliable. The ERP vendors like Oracle
Applications usually have developed some rules of thumb, for a payroll of X
number of employees you need a machine of Y capacity. And usually there is a
cushion so you err on the side of a slightly larger server than is needed.
Usually most of us develop a rough idea how many resources a process
will consume with experience, but I think that is the best you'll do. Now,
just watch someone respond and prove me wrong.
Dennis
