Re: Building Slow Development Systems (On Purpose)
Date: Wed, 27 May 2009 17:09:13 -0500
Message-ID: <3a2a84fc0905271509w363420f1g204d6abca89883a0_at_mail.gmail.com>
I do think that there's a big benefit to knowing how to make your nearly idle development machine with little load and data behave like a very busy production machine with lots of load and data. You definitely do need to "de-tune" test systems to make them exhibit the similar performance characteristics to those that will occur in anger later.
I think the athletic training analogy is right-on.
That doesn't equate to tricking developers, or giving them crappy tools or equipment. I think great developers deserve the best equipment and tools you can afford (http://www.joelonsoftware.com/articles/fog0000000043.html). But in unit testing, you need to stress your code in ways that simulate the kinds of performance problems that are going to show up in reality later. That means simulating heavily-loaded disks, queued-for CPUs, locked rows, busy buffers, and so on.
Give great developers the target of excellent performance and some understanding of how properly to measure performance (see, e.g., my "Making Friends" paper at method-r.com), and they will help figure out how to design tests that shorten the feedback loop on production performance problem detection and repair.
Cary Millsap
Method R Corporation
http://method-r.com http://carymillsap.blogspot.com http://twitter.com/cary_millsap
On Wed, May 27, 2009 at 3:43 PM, Mathias Magnusson < mathias.magnusson_at_gmail.com> wrote:
> Try creating a raid 5 where you stick all tables and indexes where it is
> made up of different partitions from the same disk. That should make
> it sufficiently slow.
>
> But I do not see this as working at all. One place I know that has a
> similar situation (not on purpose, but it is very slow) has a culture of "it
> doesn't matter, we know it will be much faster in production". There is also
> a general rule of not trying to create a system to outsmart developers
> because they will outsmart the system.
>
> I really don't think that approach works at all. If a developer is curious
> to learn how to do it well, he/she may well also figure out that they have a
> clueless DBA when it comes to supporting development to become productive.
>
> Would it be good to remove OEM and such tools, take away SQL trace as well
> as all Oracle tables and leave the DBA with nothing but the raw 10046 trace
> (not allowed to format it) to make sure they learn how to tune with just
> pure raw data? Most DBAs would just return top the time where god
> performance was a result of black magic and a few lucky people would know a
> little more and go from place to place with their magic wand.
>
> I do not believe in slowing people down by giving them an environment that
> does not perform like production. One side effect could be that things gets
> developed that are heave on CPU, takes much longer than it should and wastes
> a resource more precious than I/O.
>
> Why not try something as novel as talking to the developers? If the benefit
> of making something faster isn't enough, then maybe the ROI for the whole
> organization just isn't there. Maybe making our lives easier isn't what is
> in the best interest of the whole organization. Surely, having developers
> that understands the database is much better than developers that thinks it
> is just horribly slow and you should do what you can to not use it.
>
> Mathias
>
> On Wed, May 27, 2009 at 9:39 PM, Stephane Faroult <sfaroult_at_roughsea.com>wrote:
>
>> Kerry,
>>
>> I think it's a great idea. I remember having read when I was a kid
>> that the guy who won the gold medal for discus throwing at the very
>> first Olympic Games had used for training a copy of the discus used by
>> athletes in the antiquity - which was must heavier than its modern
>> counterpart.
>> A very small SDU in the tnsnames.ora file could also incite developers
>> to perform fewer roundtrips. Putting redo log files on a very slow (or
>> very busy) disc could calm down folks that commit every row they insert.
>> The sad thing is that I don't see how to make PL/SQL cursor loops slower
>> than they are ...
>>
>> HTH
>>
>> SF
>>
>>
>> Kerry Osborne wrote:
>> > Hey guys,
>> >
>> > I did a post yesterday about a conversation I had regarding
>> > "encouraging" developers to write tighter code by intentionally
>> > hampering development system capabilities. Specifically, using a very
>> > small buffer cache which basically turns all the lio's into pio's,
>> > thus (theoretically) encouraging developers to minimize lio's. There
>> > have been some good comments already but I thought I would poll you
>> guys.
>> >
>> > My initial reaction to the idea was that it was just plain crazy.
>> > But for some reason, over the last several days, the idea keeps
>> > popping up to the top of the stack in my brain. I fully expect to get
>> > flamed a bit, but I'll try not to take it personal. I would request
>> > that you give it an hour or two to roll around in your brain before
>> > you respond. It is a bit counter intuitive and it is certainly counter
>> > to what I've always thought of as the "ideal", which is DEV being an
>> > exact duplicate of PROD in every respect (I'm still waiting to see my
>> > first one of those by the way).
>> >
>> > Note that my conversation was about DEV environments, not QA
>> > environments. QA environments should, IMHO, always be as close to PROD
>> > as possible (same stats, etc...) But maybe there is an argument for
>> > "encouraging" developers to minimize lio's.
>> >
>> > Feel free to flame away.
>> >
>> > Kerry Osborne
>> > Enkitec
>> > blog: kerryosborne.oracle-guy.com
>> >
>> >
>> >
>> >
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 27 2009 - 17:09:13 CDT