In this episode Andreas Grabner will discuss how to get started monitoring the performance of your application using tools like Dynatrace’s free Appmon.
Discover some key performance indicators you need to know when analyzing your application performance logs. Andy will also share some of the common performance patterns he has seen after helping hundreds of folks analyze their performance issues.
About Andreas Grabner
Andreas Grabner has been a developer, tester, architect, and product evangelist for the past 18 years for CRM, eGovernment, testing and monitoring vendors. In his current role he helps companies injecting metrics into the end-to-end delivery pipeline to make better decisions on feature and code changes and with that also closing the feedback loops between Ops, Biz and AppDev. Andreas has been speaking at meetups, user groups, and international conferences to share experiences and stories around architecture, agile transformation, automated testing, CI/CD and DevOps.
In his spare time you can find him on the salsa dance floors :-).
Quotes & Insights from this Test Talk
- So I think it has changed dramatically. I think the role of head of a performance Tester has changed. I mean I’m sure there still are bodies out there that with more endings with this way because maybe just a little of what traditional software engineering but the people that I talk to. Everything moved towards automation easier to use consume fully integrated into the pipeline getting more performance feedback mother Diana to release cycle constantly with every build. And I think that’s that’s the big observation that I make. And all these different answers to this I believe that might still be some notion that you know performance testing is still too hard. And there are still these enterprise tools out there that are just built for the enterprise and therefore we don’t want to deal with it because they’re not flexible enough and that’s not true anymore. You know you also also all these enterprise tools that we have worked with in the past. They matured a lot and they are now fully integrated into your pipeline. So that’s not an excuse and what it might be a lack of education.
- When we talk about performance tests then include them into the pipeline. It doesn’t mean that we always have to execute in a long running performance tests like hours and hours to get performance feedback. I think the key and the goal of continuous delivering continuous integration is that we integrate constantly so every code change but it doesn’t mean that we always have to run large scale load test. We also need to break the load test down into smaller components and they can run much faster. They can be focused on a particular component. And what I’ve seen a lot and what I’ve been promoting is you don’t need a large scale performance test to actually find performance problems that are related to architectural issues or basic bad implementations of of algorithms. What I’m trying to promote is if you have some existing unit tests or functional test or integration tests then don’t only look at the functional response like green or red, But look at architectural metrics and with architectural metrics.
- There’s a long list of metrics we look at. And the reason why we came up with this over the years so I’ve helped a lot of companies really analyze large scale load tests and hotspots that they found or also problems in production and most of the time if it was not a configuration problem or deployment problem but if it was really a code problem we saw there’s only a handful of problem patterns that actually cause applications not to scale or not to perform well.
- We have a tool that is called Dynatrace Appmon for application monitoring and we also have a so-called personal license that we give away for developers, architects or testers. And this is a license that you can use for free for life in your local environment local environment means you can use it on the application that you are developing or testing on your workstation.
- So what we try to solve and what these tools like Dynatrace solve is getting one consolidated view of all the information you need to analyze performance problems and that includes performance data from your web server from your app server from your database from within your application code and also from the underlying infrastructure and having all of these together in one in one part – one piece.
- I believe the best piece of advice is encourage your developers on their local stations to actually look at these performance metrics as well because basically we can avoid bad performance problems by eliminating them before it gets committed to the code base. So that’s why if you are a tester and you see problems when you analyze the code that is being developed by developers and you keep seeing the same problems encourage and educated developers to say hey maybe you want to use the same tool that I’m using. Maybe you ought to use it on your local machine so you’ll learn what the potential impact of your code change is and then fix the code to make it better before you actually committed to the CI environment. And I think that’s the best shift left that we can do.
Resources
Connect with Andreas Grabner
- Twitter:@grabnerandi
- Blog: https://www.dynatrace.com/blog/author/andreas-grabner/
- Company: Dynatrace
May I Ask You For a Favor?
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.
Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!