CHAPTER 9 PERFORMANCE AND (How to cite a web site) SCALABILITY TESTING If
CHAPTER 9 PERFORMANCE AND SCALABILITY TESTING If you recall from Chapter 5, an SLA is defined by the following three key criteria: It is specific. It is flexible. It is reasonable. The specific value measures the performance of a single request: the request must respond within three seconds. The flexibility value, however, measures the scalability of the request: the request must respond within three seconds for 95 percent of requests and may fluctuate, at most, one standard deviation from the mean. The strategy is to first ensure the performance of a request or of a component and then test the request or component for scalability. Ensuring the performance of a request or of a component depends on where your application is in the development life cycle. Optimally, you want to implement proactive performance testing in the development phase of your application, which includes developing unit tests using a unit testing framework, like JUnit, and implementing code profiling, memory profiling, and coverage profiling against those unit tests. From code profiling, you want to watch for the following three key things: Poorly performing methods Methods invoked a significant number of times Classes and methods that allocate an excessive number of objects The purpose of code profiling is to identify any egregiously slow algorithms or methods that are creating a surplus of objects; for example, trying to sort 1 million items using a bubble sort algorithm can result in up to 1012 object comparisons, which could take minutes or hours to execute. When implementing memory profiling, you look for the following two things: Loitering objects Object cycling Loitering objects, also referred to as lingering object references, are unwanted objects that stay in the heap after the end of a use case. They reduce the amount of available heap memory and typically are tied to one or more requests, so they are leading the heap down a path to its ultimate demise. Another side of memory mismanagement is object cycling, or the rapid creation and destruction of objects in the heap. While these objects do not linger in the heap and consume permanent resources, they force the garbage collector to run more frequently and hence hinder performance. Finally, coverage profiling establishes the level of confidence you have in your unit tests. The coverage profiler tells you each condition that was and was not executed for every line of code. If you test the functionality and performance of your code in unit tests, and your coverage is high, then you can feel comfortable that your code is solid. On the other hand, if your coverage is low, then you can have very little confidence in your test results.
Please visit our professional web hosting services to find out about cheap and reliable webhost service that will surely answer all your demands.