Performance Efficiency Pillar

The Performance Efficiency pillar of the Azure Well-Architected Framework focuses on ensuring your workload can scale to meet demand and use resources efficiently. It is about matching your system's capacity to the load it serves — not too much, not too little.

---

Design Principles

Scale Out, Not Up

Prefer horizontal scaling (adding more instances) over vertical scaling (using a larger instance). Horizontal scaling provides better fault tolerance and can scale to virtually unlimited capacity. Vertical scaling has physical limits and creates a single point of failure.

Use Managed Services

Azure managed services (App Service, Azure SQL, Cosmos DB) handle scaling, patching, and optimisation for you. They allow your team to focus on application logic rather than infrastructure tuning.

Design for Change

Performance requirements evolve as your workload grows. Design your architecture so that you can adjust and optimise without major re-architecture. Use loosely coupled, modular components that can be independently scaled and replaced.

Measure Performance

Establish performance baselines and continuously measure against them. Without measurements, you are guessing. Use load testing, performance monitoring, and capacity planning to make data-driven decisions.

---

Scaling Strategies

Horizontal Scaling (Scale-Out)

Add more instances to handle increased load:

Azure Service	Scaling Mechanism
Virtual Machine Scale Sets	Auto-scale based on CPU, memory, or custom metrics
App Service	Auto-scale rules in the App Service plan
Azure Functions	Automatic scaling (Consumption and Premium plans)
Azure Kubernetes Service	Horizontal Pod Autoscaler (HPA) and Cluster Autoscaler
Cosmos DB	Autoscale throughput (RU/s)

Vertical Scaling (Scale-Up)

Increase the size of a single instance:

• Upgrade a VM from Standard_D2s_v5 to Standard_D4s_v5
• Move from General Purpose to Business Critical tier in Azure SQL

Vertical scaling is simpler but has limits and may cause downtime during the resize. Use it when horizontal scaling is not feasible (e.g., single-instance databases).

Autoscaling Best Practices

• Scale based on metrics that correlate with user experience (request queue length, response time) rather than just CPU
• Set minimum and maximum instance counts to prevent over-scaling and ensure baseline availability
• Configure scale-in cooldown periods to prevent thrashing (repeatedly scaling in and out)
• Test your auto-scale rules under realistic load conditions

---

Caching

Caching reduces latency and backend load by serving frequently accessed data from a fast, in-memory store.

Azure Cache for Redis

Azure Cache for Redis is a fully managed, in-memory data store:

Use Case	Description
Data cache	Cache database query results to reduce database load
Session store	Store user session data for web applications
Message broker	Use Redis pub/sub for real-time messaging
Rate limiter	Track request counts per user or IP
Leaderboard	Use Redis sorted sets for ranked data

Caching Patterns

• Cache-aside — the application checks the cache first; on a miss, it reads from the database and populates the cache
• Write-through — the application writes to the cache and database simultaneously
• Write-behind — the application writes to the cache, which asynchronously writes to the database

CDN (Content Delivery Network)

Azure CDN caches static content (images, CSS, JavaScript) at edge locations close to users worldwide:

• Reduces latency for global audiences
• Offloads traffic from your origin servers
• Integrates with Azure Blob Storage, App Service, and custom origins

---

Database Performance

Azure SQL Performance Tips