The details concerning how you can do this kind of cost-benefit analysis for your cloud applications will be discussed in the upcoming GCAP class and the PDQW workshop. Check the corresponding class registration pages for dates and pricing.
Possibly pithy insights into computer performance analysis and capacity planning based on the Guerrilla series of books and training classes provided by Performance Dynamics Company.
The details concerning how you can do this kind of cost-benefit analysis for your cloud applications will be discussed in the upcoming GCAP class and the PDQW workshop. Check the corresponding class registration pages for dates and pricing.
Exposing the Cost of Performance
Hidden in the Cloud
Neil Gunther
Performance Dynamics, Castro Valley, California
Mohit Chawla
Independent Systems Engineer, Hamburg, Germany10am Pacific Time on June 19, 2018
Whilst offering lift-and-shift migration and versatile elastic capacity, the cloud also reintroduces an old mainframe concept—chargeback—which rejuvenates the need for performance analysis and capacity planning. Combining production JMX data with an appropriate performance model, we show how to assess fee-based EC2 configurations for a mobile-user application running on a Linux-hosted Tomcat cluster. The performance model also facilitates ongoing cost-benefit analysis of various EC2 Auto Scaling policies.
Guerrilla CaP for Noobs and Nerds
Whether you're a newbie (noob) or a veteran (nerd) when it comes to capacity planning (CaP) and performance analysis, it never hurts to revisit the fundamentals. However, some CaP concepts that are touted as fundamental are actually myths. Here are some myths I hear all too often.
What's NOT:
During my twin session I will take these myths apart to expose the facts in terms of
- We don't need no stinkin' CaP, just more cheap servers.
- CPU utilization should never exceed 70% busy.
- A well-consolidated server should have no idle cycles.
- Throughput and latency are independent metrics that must be measured separately.
- Optimal response time is achieved at the knee of the curve.
- If you can measure it, you can manage it.
What's HOT†:
Along the way, I'll offer some Guerrilla mantras, as seen in my Guerrilla book and generated automatically on Twitter. You can use them as weapons of mass instruction to bust any other myths held by your colleagues and managers, whether you're a noob or nerd.
- If the app is single-threaded, a boat-load of cheap servers from China won't help.
- A 64-way server running 70% busy is 25% underutilized.
- A consolidated server may need to be under 10% busy to meet app SLAs.
- Throughput and latency are inversely related ... always!
- Response time knees are an optical illusion.
- All performance measurements are wrong by definition.