PurePerformance

Alois Reitbauer (@AloisReitbauer) guest hosts - Mike Jones ( http://bit.ly/mjlnk ) takes us on a journey how the team moved a monolithic application that was built by a remote team to a micro service architecture. Learn how the manage a couple of million lines of code with only 5 people while improving performance and availability. Mike also shares lessons learned on their journey and shares strategies on how to make the transition to micro services while having to keep the lights on for day-to-day business.

Scott Stocker (@sestocker), Solution Architect at Perficient, tells us the background of a recent load testing engagement on an ASP.NET App running on SiteCore. Turns out that even these apps on the popular Microsoft platform suffer from the same architectural and implementation patterns as we see everywhere else. Bypassing the caching layer through FastQuery resulted in excessive SQL, which caused the system to not scale, but crumble. Scott tells us how they identified this issue and what his approach as an architect is to proactively identify most common performance and scalability problems.

The initial idea of the Cloud has long become commodity – which is IaaS. Containers are the current hype but still require you to take care of correctly configuring your container that will run your code. Mike Villiger (@mikevilliger) – a veteran and active member of the cloud community – explains why it is really PaaS that should be on top of your list. And why monitoring performance, architecture and resource consumption is more important than ever in order for your PaaS Adventure not to fail.Related article:http://www.it20.info/2016/03/the-incestuous-relations-among-containers-orchestration-tools/

In Part II, Richard Dominguez, Developer in Operations at PrepSportswear, is explaining the significance of understanding and dealing with bot and spider traffic on their eCommerce site. He explains why they route search bot traffic to dedicated servers, how to better serve good bots and how to block the bad ones. Most importantly: we learn about a lot of metrics he is providing for the DevOps but also the marketing teams to run a better online experience!

Have you ever wondered how to argue with a marketeer about not releasing a new feature or running this campaign? Or in the contrary: how can you show a marketeer that performance engineering and monitoring is as critical to the success of a campaign as the marketing campaign itself? Richard Dominguez, Developer in Operations at PrepSportswear, is enlightening us about how his DevOps team is cooperating with marketing to have a better shared understanding between business and technical goals!

Microsoft is doing a good job in shielding the complexity of what is going on in the CLR from us. Until now Microsoft is taking care to optimize the Garbage Collector and tries to come up with good defaults when it comes to thread and connection pool sizes. The problem though is that even the best optimizations from Microsoft are not good enough if your application suffers from poor architectural decisions or simply bad coding.Listen to this podcast to learn about the top problems you may suffer in your .NET Application. We have many examples and we discuss how you can do a quick sanity check on your own code to detect bad database access patterns, memory leaks, thread contentions or simply bad code that results in high CPU, synchronization or even crashes!

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.