API Performance Metrics and Optimization

Why Measure API Performance

API документацию are the backbone of modern web applications. A slow API means a slow website, poor user experience, and lost customers. According to Amazon, every 100ms of latency reduces sales by 1%. For APIs serving frontends, this is critical.

Without metrics, you don't know how fast your API performs, where bottlenecks are, or when degradation begins.

Key Metrics

Latency

Time from sending a request to receiving a response. The primary user experience metric.

How to measure:

• Average — misleading. Can hide problems: if 99 requests take 100ms and 1 takes 10 seconds, the average is 199ms
• Median (P50) — 50% of requests are faster. Represents typical experience
• P95/P99 — 95%/99% of requests are faster. Shows the tail — worst-case experience
• P99.9 — for high-traffic APIs, critical for SLA

Target values:

• P50: under 100ms for internal APIs, under 200ms for public
• P95: under 500ms
• P99: under 1 second

Throughput

Number of requests processed per unit of time (RPS — Requests Per Second). Shows system capacity.

Monitor throughput alongside latency. Increasing RPS often causes latency to rise — knowing the degradation point is crucial.

Error Rate

Percentage of requests that end in error (HTTP 4xx, 5xx). Target: less than 0.1% for 5xx errors.

Distinguish between:

• 4xx — client errors (validation, authorization). Not always a server problem
• 5xx — server errors. Always require attention
• Timeout — request received no response. Often the most damaging error

Availability

Percentage of time the API responds correctly. SLA typically defines target uptime:

• 99.9% — no more than 8.7 hours downtime per year
• 99.99% — no more than 52.5 minutes per year

Saturation

How loaded resources are: CPU, memory, DB connections, disk I/O. When saturation approaches 100%, latency spikes dramatically.

The RED Methodology

RED (Rate, Errors, Duration) is a simple methodology for monitoring microservices:

• Rate — requests per second
• Errors — failed requests per second
• Duration — response time distribution (histogram)

These three metrics cover 80% of API monitoring needs.

API Performance Optimization

Database Queries

• Use indexes for frequent queries
• Avoid the N+1 problem (1 query for list + N queries for details)
• Cache frequently repeated query results in Redis
• Use pagination instead of loading all records

Caching

• Redis/Memcached for hot data
• HTTP caching (Cache-Control, ETag) for public endpoints
• In-request computation memoization

Compression

Enable gzip/brotli for JSON responses. For large JSON responses, compression can reduce size by 80-90%.

Pagination and Filtering

Don't return 10,000 records in a single response. Use cursor-based or offset-based pagination. Let clients filter data server-side.

Monitoring and Tools

Use the Enterno.io HTTP Checker to verify response times and headers of your API endpoints. Set up uptime monitoring for key endpoints to receive notifications on degradation.

Summary

Monitor latency (percentiles, not averages), throughput, error rate, and saturation. Use the RED methodology for microservices. Optimize database queries, cache hot data, compress responses. Set SLAs and monitor compliance.