6.11 Race and Load Conditions

 < Day Day Up > 



A race condition is best defined as one event preceding another. The trick is making sure the first condition should be first or the last condition is supposed to be last. Few programmers think about or even check for race conditions. These conditions are sometimes identified only after great labor has been expended in doing traces into executable code, step by step, to see what is happening. When you hear the word irreproducible as testers are talking about this type of bug, interpret it to mean a possible race condition and ask if they have checked for it.

Load conditions are common and are the result of putting more work on the computer than it can bear. A simple point of illustration is having a computer process millions of records. It is the perfect job for a computer, but when the time to process each record is more than a few milliseconds, the million records to be processed can take a great deal of time. For example, let’s assume an ideal situation where your application does some complex validation necessary to properly process a record and that it takes 10 milliseconds to process each of these records in a perfectly managed test environment. This translates to a processing rate of 100 records per second. Not bad, but when you divide 100 into 1 million records, you quickly find out that this job will take 10,000 seconds or 2.7 hours to run to completion. Again, this is acceptable in most cases, except that you must remember the machine is completely tied up with processing. No reports can be produced, no queries can be run, and so on. In today’s modern computing environment, this is not acceptable.

Let’s take another view where real-world conditions are applied. In a test environment, where the 10 milliseconds are ideal computing conditions, we will compound the problem with user interaction and system overhead. Let’s look at record retrieval times and factor them into the equation. Your 10 milliseconds are now 14.5 milliseconds per record. User queries and other user interactions could easily add another 10 or so milliseconds per activity, and now we are at 25 milliseconds of processing time for just a single record. We are now looking at 6.75 hours to run the same job that ran in 2.7 hours in the test lab. The point here is that testing should account for such load conditions before release into production. If users know before kicking off a production job that it will take 7 hours to run, they can go off and do other things or run the job at night; however, if they expect is a 2.5-hour job, they will always be dissatisfied with performance because it is not what they expected.



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net