| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
Browse archives
Search |
Application lifecycle performance testing and monitoring strategiesApplication lifecycle performance testing and monitoring strategies on SearchSoftwareQuality by Mike Kelly is an interesting read that has some good info about load and performance testing. Selected quotes: "Application performance is often a series of tradeoffs that occur throughout the application lifecycle." "If we allow for emergent design, we may not recognize the need for a focus on low-level performance metrics early in the project" "This is why application performance testing and monitoring can be so important for some projects. As teams work to test pre-production, and monitor post-production, they are often looking to tune their application to an ever-changing operating environment with an evolving user population. Tuning application performance isn't unlike sound-mixing – where you're asking people with some specialized skills to "listen" to your application and move a bunch of knobs, sliders, and dials to obtain optimal performance." "Netflix who, by enabling gzip compression for plain text components, noticed a sudden drop in outbound network traffic. This drop lowered their bandwidth bill by 43%." "Take the time to define both top-line and bottom-line application business metrics for your project." "Identify what processes and transactions will affect those key metrics.... At the end of this exercise, you might have a taxonomy of different aspects of your system and how they might affect key business metrics. "Teams can often use performance targets and goals to drive down to specific service level agreements (SLAs) around performance. By defining low-level SLAs across the application, each team or developer knows how fast their code needs to be. It also means they know performance is now their business, not someone else's. They can't (reasonably) put off that testing until the end, because they know what they're going to be held accountable to. And in my experience, most teams want to know this information. They don't like the surprise later on." "Not understanding or anticipating the different usage models for your application can lead to a false sense of security around your test coverage." "All of this points to thinking about performance issues while you're writing code. That's also the best time to be thinking about how you're going to answer questions about performance in production." It's also a bit confusing how this article has Mike Kelly's name and photo at the top, but it has an "About the Author" at the bottom that says this: Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: christopher.mcmahon@gmail.com. By admin at Apr 7 2010 - 1:20am | admin's blog
|
NavigationUser loginSyndicate |