PurePerformance

The Java Runtime has become so fast that it shouldn’t be the first one to blame when looking at performance problems. We agree: the runtime is great, JIT and garbage collection are amazing. But bad code on a fast runtime is still bad code. And it is not only your code but the 80-90% of code that you do not control such as Hibernate, Spring, App-Server specific implementations or the Java Core Libraries.Listen to this podcast to learn about the top Java Performance Problems we have seen in the last months. Learn how to detect bad database access patterns, memory leaks, thread contentions and – well – simply bad code resulting in high CPU utilization, synchronization issues or even crashes!

How can you performance test an application when you get a new build with every code check-in? Is performance testing as we know it still relevant in a DevOps world or do we just monitor performance in production and fix things as we see problems come up?Continuous Delivery talks about breaking an application into smaller components that can be tested in isolation but also deployed independently. Performance Testing is more relevant than ever in a world where we deploy more frequently – however – the approach of executing these tests has to change. Instead of executing hourly long performance test on the whole application we also need to break down these tests into smaller units. These tests need to be executed automatically with every build – providing fast feedback on whether a code change is potentially jeopardizing performance and scalabilityListen to this podcast to get some new insights and ideas on how to integrate your performance tests into your Continuous Delivery Process. We discuss tips&tricks we have seen from engineering teams that made the transition to a more “agile/devopsy” way to execute tests

Have you ever wondered what other people mean when they talk about a performance or load or stress test? What about a penetration test? There are many definitions floating around and things sometimes get confused.Listen to this podcast and let us clarify for you by giving you our opinion on the different types of tests that are necessary when testing an application. In the end you can make up your own mind what best term to use.Special Guest: Mark Tomlinson (@mtomlins) of PerfBytes

If you are running load tests it is not enough to just look at response time and throughput. As a performance engineer you also have to look at key components that impact performance: CPU, Memory, Network and Disk Utilization should be obvious. Connection Pools (Database, Web Service), Thread Pools and Message Queues have to be part of monitoring as well. On top of that you want to understand how your individual components that you test (frontend server, backend services, database, middleware, …) communicate with each other. You need to identify any communication bottlenecks because of too chatty components (how many calls between tiers) and to heavy weight conversations (bandwidth requirements).Listen to this podcast and learn which metrics you should look at while running your load test. As performance engineer you should not only report that the app is slow under a certain load but also give recommendations on which components are to blame.