More and more, IT leaders are realizing the need for performance engineering. Now these leaders look at the performance impact before releasing changes to applications. All of us working in the software value stream know how the validation of performance requirements is so often put off until the last minute, due to the big effort involved. This task, which needs to be done manually, involves critical resources that will already be overstretched. In this post, I’ll give you some ideas on how to simplify performance engineering.
What are the challenges in performance-engineering assignments?
Nobody takes responsibility for it: The UI mockups are looking good, and there are detailed documents for all the new features. But from the business through the development, testing and operational teams, nobody stops to consider the missing performance requirements. The project starts in full swing with no thought of the thing that annoys customers the most—bad performance!
Functional-oriented design and development: Due to the absence of performance requirements, the developers concentrate on the functionality of their new applications. This focus on functional-oriented design often results in severe bottlenecks. If thousands across the globe are expected to use your application, but nobody has added this factor in the requirements, you’ll end up in a bit of a fix! You’ll end up spending thousands on fixing the hotspots because your developers won’t have incorporated these vital requirements into their design and implementation.
Technology is changing all the time: From frontend to backend, network, virtualization and data storage, the technological enhancements are unstoppable. Performance engineers working with old tool sets are often badly affected by new technology stacks, and finding workarounds for integrating their equipment makes them lose a lot of time!
Complexity is increasing: An average application uses more than 80 servers and over 200 services. Performance engineers often have a hard time tracing the transactions from a user request to the corresponding backend calls. The engineers need to trace every single transaction to identify the cause of slowdowns. At the same time, log file-based tracing is often just a road to nowhere.
Invalid user-simulation approach: There are so many performance-testing tools on the market, it can be hard to decide which load-testing tool will be best. How can you identify the one that’s most appropriate for your application under test? You can’t run an accurate load test with a protocol-level user simulation if, for example, you’re going to load test a web-based application that’s mainly based on asynchronous communication and web2.0 technology such as AJAX .
User and transaction volumes are not appropriate: The number of users and the number of actions they execute per interval strongly impact your application. These factors influence the response times and reliability of the other applications working with yours at any given time. If your figures are invalid, you’ll tune the system in the wrong way in your performance tests, and create sunk costs.
In my next post, I’ll share some ideas on how you can overcome such challenges in your next performance-engineering assignment.
Keep doing the good things. Happy Performance Testing!