Better Software - April 2009 - (Page 27) Figure 2: Traditional approach to performance testing Network issues: • IP connections and the use of HTTP • Excessive use of security features • Type and characteristic of load balancers • Possible over-interaction between application servers and database servers • Sizing of packets (size in application versus size on network) • Connection pools and connection sharing • Location of servers on the network • Increased latency and jitter Application issues: • Excessive memory allocation and de-allocation • Improper task initialization and housekeeping • Improper garbage collection, especially after a fault or failure • Loss of sessions or sessions kept alive too long (timers) • Persistent applications like BlackBerry devices • Application configuration parameter conflicts • High resource consumption features (CAD/CAM, etc.) Database issues: • Index design • Use of dynamic indexes • Potential deadlocks from locking contention • Inefficient use of cache • Overuse of cache • Use of resource-intensive features such as referential integrity • Use of stored procedures or trigger events • Table fragmentation (overuse of third normal form) • Improper timing of table and index reorganization If you can identify performance problems before they get engineered into the system, they are far less expensive to correct. Granted, this may slow down the project as the requirements or designs need to be reworked and corrected. The time required later to correct design flaws will have an even greater impact on the project, as a major redesign effort APRIL 2009 BETTER SOFTWARE Figure 3: Incremental and iterative development allow early performance testing. • There are many complex, poorly understood, and hidden interdependencies. • OFAT takes too long. • Other methods (typically multifactor-at-once adjustments) are harder to apply well. For example, once the database is “fixed” and the test rerun, we may discover new problems in the network or application that have to be fixed, which in turn creates more problems in the database. It is possible to end up in a continuous loop, going from one factor to the next and back again. Yes, the performance test does require a stable environment and software. However, this does not mean all features have to be completed. Using a combination of preventive thinking (static testing) and incremental or iterative development, it is possible to start performance testing as soon as there are one or two functionally stable features available. Incremental and iterative styles of application development offer a great opportunity to implement performance testing early in a project. By identifying performance problems early in the development process, there are more opportunities to fix the design and architecture before the costs of those corrections become too high. Figure 3 shows an example. Using simple review techniques with a focus on performance testing rather than engineering the functionality, we can include features with potential performance impacts in the earlier builds and releases. This may affect project schedules, as features that impact performance may also be more complex to develop. Once the first build is functionally tested, the performance test group can start testing while the functional team continues to develop the next increment. The advantage to this approach is twofold: The infrastructure gets an early test and, as there is a limit to completed features, changes to the system architecture or design are far less costly. The drawback to this approach is the more complex coordination between the functional test team and the performance test team. Performance testing cannot have activities occurring on the infrastructure or architecture that are not part of the controlled test. Below are lists of potential network, application, and database problems that can be detected during the early stages of the development process using static methods: www.StickyMinds.com 27 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.