Performance

Performance Optimization

Performance work follows one rule above all others: measure before you change anything. Intuition about bottlenecks is wrong more often than it is right. Every optimization should start with profiling, produce a hypothesis, apply a targeted fix, and verify with another measurement.

Core Principles

Profiling and Benchmarking

Profiling identifies where time and resources are spent. Without it, you are guessing.

Types of Profiling

The Profiling Workflow

1. Baseline - Capture metrics under normal conditions before any changes
2. Identify - Find the hotspot consuming the most time or resources
3. Hypothesize - Form a specific theory about why it is slow
4. Fix - Apply a single, targeted change
5. Verify - Measure again to confirm improvement and check for regressions

Performance Budgets

Define limits that trigger action when exceeded:

• Response time: P50, P95, P99 latency targets per endpoint
• Throughput: Minimum requests per second under expected load
• Resource usage: CPU, memory, and connection limits per service
• Page weight: Maximum transfer size for frontend assets

See Profiling Patterns Reference for detailed profiling workflows, bottleneck signatures, and load testing strategies.

Caching Strategies

Caching eliminates redundant computation and data fetching by storing results closer to where they are needed.

Cache Layers

Invalidation Approaches

Cache Stampede Prevention

When a popular cache key expires, many concurrent requests may all try to regenerate it at once, overwhelming the backend. Three approaches prevent this:

• Locking - Only one request regenerates; others wait or serve stale data
• Probabilistic early recomputation - Requests randomly refresh the cache before expiration, spreading regeneration over time
• Request coalescing - Duplicate in-flight requests are collapsed into a single backend call

See Caching Strategies Reference for implementation patterns with multi-language examples.

Database Optimization

Database queries are the most common performance bottleneck in web applications.

Index Strategy

• Create indexes on columns used in WHERE, JOIN, and ORDER BY clauses
• Use composite indexes that match your most frequent query patterns (leftmost prefix rule)
• Covering indexes include all columns a query needs, avoiding table lookups entirely
• Monitor unused indexes - they slow down writes without helping reads

N+1 Query Prevention

The N+1 problem occurs when code fetches a list of N records, then issues one additional query per record to load related data. Instead of 1 query, you execute N+1.

Detection signals:

• Query count scales linearly with result set size
• Many nearly identical queries differing only in a single parameter
• Profiler shows dozens or hundreds of queries for a single page load

Prevention strategies:

• Eager loading (JOIN or separate batch query upfront)
• Batch loading (collect IDs, fetch all related records in one query)
• DataLoader pattern (automatic batching and deduplication within a request)

Connection Pooling

Opening a database connection is expensive (TCP handshake, authentication, TLS negotiation). Connection pools maintain a set of reusable connections:

• Size the pool based on expected concurrency - too small causes queueing, too large overwhelms the database
• Always return connections to the pool promptly - leaked connections exhaust the pool
• Set idle timeouts to reclaim unused connections
• Use external poolers (like PgBouncer for PostgreSQL) when application-level pooling is insufficient

See Database Optimization Reference for query patterns, explain plan analysis, and multi-language examples.

Memory and Resource Management

Memory Optimization Patterns

Lazy Loading

Lazy loading defers work until the result is actually needed. It reduces startup time and memory usage but adds complexity and can cause unexpected latency later.

Where lazy loading helps:

• Loading related database records only when accessed
• Initializing expensive service connections on first use
• Loading UI components or assets only when they become visible

Where lazy loading hurts:

• When the deferred work always happens anyway (just adds overhead)
• When it moves latency from a predictable startup phase to unpredictable user interactions
• When it creates N+1 query patterns (see Database Optimization above)

Batch Operations

Replace individual operations with batch alternatives wherever possible:

• Batch inserts instead of inserting one row at a time
• Batch API calls instead of calling an external service N times
• Bulk file operations instead of processing files individually

Quick Reference: Common Bottleneck Patterns

Reference Files

Integration with Other Skills