Thanks a lot, Cary. Yes, this sentence on p.248:
"As long the execution of each business function can be expressed in terms of an LIO count, you can translate the queueing model's output in terms of business function response time and throughput" was the one I marked as something to go back to, as I didn't really understand it. Thanks, Boris Dali. --- Cary Millsap <[EMAIL PROTECTED]> wrote: > Boris, > > I think I covered this in my response to Ryan. It > was the "two stages" > part. > > Note that you can avoid even using queueing theory > at all if you just > make sure that utilization stays to the left of the > knee in the > performance curve for each resource on the system. > You can learn the > location of the knee for a given number of parallel > service channels > (for example, CPUs in your case) on Table 9-3 on > p260 of "Optimizing > Oracle Performance." > > > Cary Millsap > Hotsos Enterprises, Ltd. > http://www.hotsos.com > > Upcoming events: > - Performance Diagnosis 101: 12/16 Detroit, 1/27 > Atlanta > - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas > - Hotsos Symposium 2004: March 7-10 Dallas > - Visit www.hotsos.com for schedule details... > > > -----Original Message----- > Boris Dali > Sent: Sunday, December 07, 2003 12:39 PM > To: Multiple recipients of list ORACLE-L > > Thanks for the clarifications, Cary. > > With regards to a hardware sizing - how do LIOs fit > into queueing theory? Let's say I can come up with > something like: > > #CPUs required = Sum( LIOs(Bus.Tx i)) / > (10,000*clock rate/100) > > where i={Bus.Tx 1..n} > > [on a projected box that haven't been bought yet, it > might be a little difficult to estimate the > denominator, ... and on the existing one I guess I > have to get hold of Jonathan's paper to learn how > this > can be done] > > ..but in any event for forecasting purposes, how > queueing effect might be taken into account here? > Let's say I measured Sum( LIOs(...)) for a 50 users > in > a unit testing environment and I am told that > production would be 10 times more than that, what do > I > do? > > Thanks, > Boris Dali. > > --- Cary Millsap <[EMAIL PROTECTED]> wrote: > > My answers are in-line, preceded with "[Cary > > Millsap]"... > > > > > > Cary Millsap > > Hotsos Enterprises, Ltd. > > http://www.hotsos.com > > > > Upcoming events: > > - Performance Diagnosis 101: 12/16 Detroit, 1/27 > > Atlanta > > - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas > > - Hotsos Symposium 2004: March 7-10 Dallas > > - Visit www.hotsos.com for schedule details... > > > > > > -----Original Message----- > > Boris Dali > > Sent: Sunday, December 07, 2003 9:54 AM > > To: Multiple recipients of list ORACLE-L > > > > Thanks a lot for the reply, Cary. Yes, your > > explanation makes all the sense in the world even > > though it is precisely the weighted average > approach > > that I've seen on some capacity planning > > spreadsheets. > > > > Two additional questions if I may, Cary. > > Would it be correct to say that when I throw > > additional users on a system it is only queueing > > component of a response time that climbs up, while > > service time stays the same? > > > > [Cary Millsap] "Sort of," but not exactly. There > are > > lots of scalability > > threats that begin to manifest in reality when you > > crank up the load. > > For example, you'll see "latch free" waiting on > > applications that parse > > too much, but only at higher user volumes (never > in > > unit test). You can > > consider the new appearance of "latch free" events > > to be a type of > > queueing if you want, but it's really not queueing > > in the sense of a > > simple CPU queueing model. > > > > If that's true, than does > > it matter how I measure service time of my Bus.Tx1 > - > > on a loaded system where hundreds of users run > this > > operation or when nobody executes it all? Also is > it > > important to have the other two operations - > Bus.Tx2 > > and Bus.Tx3 - running concurrently (as they would > in > > a > > real life) for the c measurements? > > > > [Cary Millsap] You'll put yourself at risk if you > > simply try to use a > > queueing model to extrapolate big-system > performance > > from data collected > > in a unit testing environment. It's because of the > > potentially > > out-of-model scalability threats. > > > > In other words assuming I have an identical > replica > > of > > a production environment where I am the only user > - > > would service time/rate measured there be > applicable > > for a loaded system with heterogeneous workload? > > > > [Cary Millsap] ...Only if you your production > > environment doesn't > > trigger any new serialization issues that weren't > > visible on your unit > > test env. > > > > And another stupid question. > > Knowing individual business tx. characteristics > > (response time, number of CPUs required to comply > > with > > SLA requirements, average utilization per CPU, > etc), > > how does one go about sizing the box in terms of > the > > overall "system" required CPU capacity? Or put it > > another way - what do I tell a hardware vendor? > > > > That is, if what comes out of a queueuing exercise > > is: > > m pho > > -------- --- > > Bus.Tx1 2-way 70% > > Bus.Tx2 3-way 50% > > Bus.Tx3 4-way 80% > > > > What should be the optimistic (let's assume > perfect > > liner CPU scalability for now) recommendation to > > decision makers in terms of the horsepower > required > > to > > run this "system" on? > > After all, yes individual business transactions > have > > their own SLA requirements (e.g. worst tolerated > > response time), but they all use the same > resources, > > don't they? So even though a service time of > Bus.Tx1 > > might remain constant the queueing delay (and > hence > > the response time) would likely to increase due to > > other concurrent activities on the system. Is > there > > a > > way to account for this if capacity planning is > done > > at the individual bus.tx level? > > > > [Cary Millsap] The hardest part about capacity > > planning is that there's > > no useful industry-wide standard unit of CPU work > to > === message truncated === ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
