Re: Batch process resource estimation?

Hi Carry

Thanks for the detailes suggestions.

I just read the documentation from the Oracle Consulting Guy, I guess he has not been taught well enough at Oracle Corp because he actuallys says

"Quantify without running the process" (what the hechk!)

Or he has been taught by sales people :-P

Thanks

Alex

On 6/6/06, Cary Millsap <cary.millsap_at_hotsos.com> wrote:
>
> 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_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Dennis Williams
> *Sent:* Tuesday, June 06, 2006 11:30 AM
> *To:* ax.mount_at_gmail.com
> *Cc:* oracle-l_at_freelists.org
> *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
>
>

--
http://www.freelists.org/webpage/oracle-l