Re: Building Slow Development Systems (On Purpose)
Date: Wed, 27 May 2009 16:11:26 -0700
I think Cary is right on in saying give the developers the best machines possible and then QA on a slow machine.
A trick for bad performance is put the redo on a USB flash device which might encourage developers to commit in batches. Of course slow redo will hide other issues like buffer busy waits.
One of the big recurring issues is developers and QA running a piece of code with one user and giving it the OK. Then it hits concurrent user access in production and crashes and burns. Thus I' m excited about DB Optimizer 1.5.1which will make concurrent user load testing of code a breeze of SQL and/or Java with SQL .
Here is an example of the Load Editor
http://www.youtube.com/watch?v=2UUizGbjCkw I will put up some more fun interesting and informative example soon of the pitfalls in concurrent multi user situations.