Optimizing Performance

Strategies for identifying, analyzing, and resolving performance bottlenecks.

When to Use This Skill

• Application is running slowly
• High resource consumption (CPU, memory)
• Database queries are slow
• API response times are high
• Need to scale for more users
• Preparing for load testing

---

Performance Optimization Philosophy

The Golden Rules

1. Measure first - Never optimize without data
2. Optimize the right thing - Find the actual bottleneck
3. Keep it simple - Complexity often hurts performance
4. Test after - Verify the optimization worked
5. Document trade-offs - Performance often costs readability

The 80/20 Rule

80% of performance problems come from 20% of the code.

Focus on:
├── Hot paths (frequently executed code)
├── I/O operations (database, network, disk)
├── Memory allocation patterns
└── Algorithm complexity

---

Profiling Techniques

Types of Profiling

| Type | What It Measures | Tools | |------|------------------|-------| | CPU Profiling | Time spent in functions | pprof, py-spy, Chrome DevTools | | Memory Profiling | Allocation patterns, leaks | Valgrind, memory_profiler, Chrome | | I/O Profiling | Disk/network operations | strace, perf, Wireshark | | Database Profiling | Query performance | EXPLAIN, slow query log, APM |

Profiling Workflow

1. Establish baseline
   └─ Measure current performance with realistic load

2. Identify hotspots
   └─ Profile to find where time/resources are spent

3. Form hypothesis
   └─ Why is this slow? What would make it faster?

4. Implement fix
   └─ Make ONE change at a time

5. Measure again
   └─ Did it help? By how much?

6. Repeat
   └─ Until performance goals are met

Common Profiling Commands

# Node.js
node --prof app.js
node --prof-process isolate-*.log > profile.txt

# Python
python -m cProfile -s cumtime app.py
py-spy record -o profile.svg -- python app.py

# Go
go test -cpuprofile cpu.prof -memprofile mem.prof -bench .
go tool pprof cpu.prof

# Database (PostgreSQL)
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

---

Common Bottleneck Patterns

N+1 Query Problem

BAD (N+1 queries):
  SELECT * FROM posts;             -- 1 query
  SELECT * FROM users WHERE id=1;  -- N queries
  SELECT * FROM users WHERE id=2;
  ...

GOOD (2 queries):
  SELECT * FROM posts;
  SELECT * FROM users WHERE id IN (1, 2, 3, ...);

Detection: High query count relative to data returned Fix: Eager loading, batch fetching, JOINs

Unbounded Operations

BAD:
  SELECT * FROM logs;  -- Returns millions of rows

GOOD:
  SELECT * FROM logs
  WHERE created_at > NOW() - INTERVAL '1 day'
  LIMIT 100;

Detection: Memory spikes, timeouts Fix: Pagination, limits, streaming

Synchronous Blocking

BAD (blocking):
  result1 = fetch_api_1()  -- Wait 200ms
  result2 = fetch_api_2()  -- Wait 200ms
  return combine(result1, result2)  -- Total: 400ms

GOOD (parallel):
  [result1, result2] = await Promise.all([
    fetch_api_1(),
    fetch_api_2()
  ])  -- Total: ~200ms

Detection: Sequential I/O in traces Fix: Parallel execution, async/await

Excessive Allocation

BAD (allocates in loop):
  for item in large_list:
      result = []  # Allocates each iteration
      result.append(transform(item))

GOOD (pre-allocate):
  result = []
  for item in large_list:
      result.append(transform(item))

BEST (generator):
  def transform_all(items):
      for item in items:
          yield transform(item)

Detection: GC pressure, memory profiling Fix: Object pooling, pre-allocation, generators

---

Optimization Techniques

Database Optimization

| Technique | When to Use | Impact | |-----------|-------------|--------| | Indexing | Slow WHERE/JOIN queries | High | | Query optimization | Complex queries | High | | Connection pooling | Many short connections | Medium | | Read replicas | Read-heavy workloads | High | | Caching | Repeated queries | Very High | | Denormalization | Complex JOINs | Medium |

Index Guidelines

-- Create index for frequently queried columns
CREATE INDEX idx_users_email ON users(email);

-- Composite index for multiple column queries
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);

-- Check if index is used
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

Caching Strategies

| Strategy | Use Case | Invalidation | |----------|----------|--------------| | Cache-aside | General purpose | Manual or TTL | | Write-through | Strong consistency | On write | | Write-behind | Write-heavy | Async batched | | Read-through | Read-heavy | On miss |

Cache-aside pattern:
1. Check cache
2. If miss, query database
3. Store in cache
4. Return result

Memory Optimization

| Technique | When to Use | |-----------|-------------| | Object pooling | Frequent allocation of same type | | Lazy loading | Large objects not always needed | | Streaming | Processing large datasets | | Weak references | Cache that can be evicted | | Data structure choice | Right structure for access pattern |

---

Frontend Performance

Core Web Vitals

| Metric | Target | What It Measures | |--------|--------|------------------| | LCP (Largest Contentful Paint) | < 2.5s | Load performance | | INP (Interaction to Next Paint) | < 200ms | Interactivity | | CLS (Cumulative Layout Shift) | < 0.1 | Visual stability |

Frontend Optimization Checklist

Loading Performance:
  ☐ Code splitting (lazy load routes/components)
  ☐ Tree shaking (remove unused code)
  ☐ Minification (JS, CSS)
  ☐ Compression (gzip, brotli)
  ☐ Image optimization (WebP, srcset, lazy loading)
  ☐ CDN for static assets

Runtime Performance:
  ☐ Virtualized lists for large data
  ☐ Debounce/throttle event handlers
  ☐ Memoization of expensive computations
  ☐ Avoid layout thrashing (batch DOM reads/writes)
  ☐ Use CSS transforms for animations
  ☐ Web Workers for heavy computation

Bundle Optimization

# Analyze bundle size
npx webpack-bundle-analyzer stats.json
npx source-map-explorer bundle.js

# Identify large dependencies
npx depcheck

---

API Performance

Response Time Targets

| Percentile | Target | User Experience | |------------|--------|-----------------| | p50 | < 100ms | Fast | | p95 | < 500ms | Acceptable | | p99 | < 1s | Tolerable |

API Optimization Techniques

| Technique | Benefit | |-----------|---------| | Response compression | Reduce transfer size | | Pagination | Limit response size | | Field selection | Return only needed data | | ETags/Caching headers | Reduce redundant requests | | Connection keep-alive | Reduce handshake overhead | | HTTP/2 | Multiplexing, header compression |

Batch Endpoints

BAD (multiple requests):
  GET /users/1
  GET /users/2
  GET /users/3

GOOD (batch):
  POST /users/batch
  { "ids": [1, 2, 3] }

---

Monitoring and Alerting

Key Metrics to Track

| Category | Metrics | |----------|---------| | Latency | p50, p95, p99 response times | | Throughput | Requests per second | | Errors | Error rate, error types | | Saturation | CPU, memory, connections |

Alerting Thresholds

Critical (page immediately):
  - Error rate > 5%
  - p99 latency > 5s
  - Service down

Warning (notify during hours):
  - Error rate > 1%
  - p95 latency > 2s
  - Resource utilization > 80%

Logging for Performance

# Log slow operations
import time
import logging

def timed_operation(func):
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        duration = time.time() - start
        if duration > 1.0:  # Log if > 1 second
            logging.warning(f"{func.__name__} took {duration:.2f}s")
        return result
    return wrapper

---

Performance Testing

Load Testing Tools

| Tool | Use Case | |------|----------| | k6 | Modern, scriptable load testing | | JMeter | Complex scenarios, GUI | | Locust | Python-based, distributed | | Artillery | YAML config, easy to start | | wrk | Simple HTTP benchmarking |

Load Test Example (k6)

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 50 },   // Ramp up
    { duration: '5m', target: 50 },   // Stay at 50 users
    { duration: '1m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% under 500ms
    http_req_failed: ['rate<0.01'],    // Error rate < 1%
  },
};

export default function () {
  const res = http.get('https://api.example.com/users');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

---

Anti-Patterns to Avoid

1. Premature optimization - Optimize only proven bottlenecks
2. Optimizing without measuring - Guessing wastes time
3. Over-caching - Cache invalidation is hard
4. Ignoring database - Often the real bottleneck
5. Complex micro-optimizations - Usually not worth it
6. Not testing under load - Production behavior differs
7. Ignoring cold starts - First request matters too
8. Over-engineering - Simpler is often faster

---

Quick Reference

PROFILING FLOW:
  Measure → Identify → Hypothesize → Fix → Measure → Repeat

COMMON BOTTLENECKS:
  N+1 queries → Eager loading
  Unbounded data → Pagination
  Blocking I/O → Parallelization
  Excessive allocation → Object pooling

DATABASE:
  Index frequently queried columns
  Use EXPLAIN ANALYZE
  Add caching layer

CACHING:
  Cache-aside for general use
  TTL for time-based invalidation
  Invalidate on write for consistency

TARGETS:
  p50 < 100ms
  p95 < 500ms
  p99 < 1s

TOOLS:
  CPU: pprof, py-spy
  Memory: valgrind, memory_profiler
  Load: k6, locust
  DB: EXPLAIN, slow query log