Ted,
> >The performance gain made sense then, and it makes sense now. > > Does it with sub-5ms response? [Ron Hawkins] Yes. I usually figure out the saving with 0.35 to 1.5ms response time in SIMPLEX and 0.75 to 3ms response time in DUPLEX with Synchronous remote copy. Anything else is usually (not always) a queue. If I use 5ms response time as you suggest then the benefit is even larger. > >After all, I'm sure you are one of the supporters of the maxim "the best IO > is the one you don't do." > > Yes. But. > > >That's something compression can do for you. > > It's too expensive in a write intensive environment. [Ron Hawkins] I'm missing your point, as I didn't mention a write intensive environment. My first examples is father to son updates which is 50% write at worse, and the second example is read intensive. As the second example is not write intensive, we agree on the benefit and there is no need to debate the second example further. I apologize if it wasn't clear that I did not give examples that apply to any "environment" be it write or read intensive. This is about compressing specific datasets as an IO reduction strategy. The first example refers to compressing a loved one: those datasets that define the critical path of an application's elapsed time. I state this explicitly in the example. If the application is unimportant, or there is no measurable or tangible benefit in reducing the elapsed time then it is outside the scope of my example. Ron > > - > I'm a SuperHero with neither powers, nor motivation! > Kimota! [Ron Hawkins] I always wondered why atomic ended with a K... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
