Kong Gateway Performance Optimization: AI-Optimized Technical Reference

Executive Summary

Kong Gateway performance degrades significantly from marketing benchmarks (50,000+ RPS) to production reality (8,000-28,000 RPS depending on plugin load). Performance bottlenecks occur at database connections, plugin processing overhead, memory cache limitations, and network configuration. Critical optimization requires specific configuration changes, not just infrastructure scaling.

Performance Baselines and Reality

Realistic Performance Expectations

• Bare Kong (no plugins): 35,000-45,000 RPS on 8-core, 16GB RAM
• Essential plugins (auth, rate limiting): 20,000-28,000 RPS
• Full enterprise plugin stack: 8,000-15,000 RPS
• AI Gateway plugins enabled: 5,000-12,000 RPS

Memory Usage Reality

• Base worker process: 500MB + plugin overhead
• Production example: 4-worker instance with 500 routes and 12 plugins = 6.2GB RAM (documentation suggests 4GB - insufficient)
• Memory scaling factors: Worker count × Entity count × Connection pools

Critical Configuration Requirements

Core Performance Settings (kong.conf)

# Worker and connection settings
nginx_worker_processes = 8                # 2x CPU cores (not 1x default)
nginx_worker_connections = 4096          # 4x default for burst traffic
upstream_keepalive_pool = 512            # Prevent connection thrashing
upstream_keepalive = 1024                # Pool size per upstream

# Memory settings
mem_cache_size = 8192m                   # 8GB cache (not 128MB default)
lua_shared_dict_size = 512m              # Increase from 5m default

# Database connections (critical bottleneck)
pg_max_concurrent_queries = 50           # Per worker
pg_keepalive_timeout = 600000            # 10 minutes

# Performance logging
proxy_access_log = /dev/stdout           # Avoid disk I/O
admin_access_log = off                   # Disable admin logging
error_log = /dev/stderr warn             # Error level only

PostgreSQL Configuration Requirements

max_connections = 200                     -- 2x Kong instances × workers × pool
shared_buffers = 2GB                     -- 25% of available RAM
effective_cache_size = 6GB               -- 75% of available RAM
work_mem = 64MB                          -- For rate limiting queries
random_page_cost = 1.1                   -- SSD optimization

Plugin Performance Impact

Latency Cost Per Plugin

• Rate Limiting (database): +3-5ms, +200MB memory per worker
• Rate Limiting (Redis): +1-2ms, +100MB memory per worker
• JWT Validation: +0.5-1ms, +50MB memory per worker
• OAuth 2.0: +5-8ms, +300MB memory per worker
• Prometheus metrics: +2ms, +500MB memory (memory hog)
• Request Transformer: +1-3ms depending on complexity
• CORS: +0.5ms (efficient)

Optimal Plugin Execution Order

1. Request Termination (fail fast)
2. Rate Limiting (block early)
3. Authentication (JWT > Key Auth > OAuth)
4. Authorization (RBAC, ACL)
5. Request Validation
6. Request Transformation
7. Proxy/Upstream plugins
8. Response Transformation
9. Logging/Analytics (last - avoid processing rejected requests)

Critical Failure Points

Database Connection Exhaustion

• Problem: Default PostgreSQL 100 connections vs 4 Kong workers × 30 connections = 120 needed
• Symptoms: 502 errors under load, connection timeouts
• Solution: Increase PostgreSQL connections + PgBouncer connection pooling

Memory Cache Undersizing

• Problem: Default 128MB cache insufficient for production entity counts
• Impact: Constant database hits for configuration data
• Solution: Set mem_cache_size to 50% of available RAM

Plugin Processing Order

• Problem: Expensive plugins (logging) running before cheap rejection (auth)
• Impact: CPU waste processing requests that should be rejected early
• Solution: Reorder plugins to fail fast

Connection Pool Saturation

• Problem: Default upstream keepalive (1000) × number of upstreams = excessive connections
• Impact: Socket exhaustion, connection thrashing
• Solution: Tune upstream_keepalive_pool and upstream_keepalive

Monitoring Critical Metrics

Performance Indicators

• kong_request_duration_ms{quantile="0.95"} > 100ms = Kong bottleneck
• kong_upstream_target_health < 1 = upstream failures
• kong_memory_lua_shared_dict_bytes > 80% = memory pressure
• kong_database_reachable = 0 = database connectivity issues

Debug Commands

• CPU analysis: top -H -p $(pgrep nginx) shows worker thread CPU usage
• Connection monitoring: ss -tulpn | grep nginx tracks connection counts
• Request timing: kong config set log_level debug for latency breakdown

Scaling Decision Matrix

Scenario	Max RPS	P95 Latency	Memory/Instance	Database Load	Scaling Action
Single optimized instance	25,000	20-50ms	8-12GB	Low	Vertical scaling limit
Multi-instance cluster	100,000+	10-30ms	6-8GB each	Very Low	Horizontal scaling
Database bottleneck	Variable	>100ms	Normal	High	Redis for stateful plugins
Plugin saturation	<15,000	>200ms	High	Variable	Disable non-essential plugins

Redis Migration Requirements

Critical for Production Scale

• Database rate limiting: Becomes bottleneck at >5,000 RPS
• Redis migration: Reduces latency from 5ms to 1ms per rate limit check
• Configuration: Redis cluster required for multi-instance Kong deployments

Redis Settings

redis:
  timeout: 2000                      # Fail fast
  keepalive_pool_size: 100           # Per Kong worker
  keepalive_backlog: 50              # Connection queue

Common Failure Scenarios

502 Bad Gateway Causes

1. Backend connection limits exceeded - Check app server connection limits vs Kong upstream connections
2. DNS resolution failures - Use IP addresses or fix /etc/resolv.conf
3. Network timeouts - Reduce timeout settings, check network stability
4. Health check failures - Verify health check endpoints and intervals

Performance Degradation Over Time

1. Connection pool growth - Monitor with ss -tulpn | grep nginx
2. Plugin state accumulation - OAuth tokens, rate limit counters growing
3. Log file growth - Rotate logs aggressively
4. Lua garbage collection - Enable GC statistics monitoring

Scaling Bottlenecks at Load Increases

• 5,000 RPS threshold: Worker saturation, database pool exhaustion
• Solution order: Scale workers → database connections → optimize plugins → add instances

Resource Requirements by Scale

Small Production (5,000-15,000 RPS)

• Kong instances: 1-2
• CPU cores: 4-8 per instance
• Memory: 8-12GB per instance
• Database: PostgreSQL with 200 connections
• Redis: Single instance for rate limiting

Medium Production (15,000-50,000 RPS)

• Kong instances: 3-5
• CPU cores: 8-16 per instance
• Memory: 8-16GB per instance
• Database: PostgreSQL with PgBouncer connection pooling
• Redis: Redis cluster for high availability

Large Production (50,000+ RPS)

• Kong instances: 5+ (horizontal scaling)
• CPU cores: 8-16 per instance
• Memory: 12-24GB per instance
• Database: PostgreSQL cluster with dedicated connection pooling
• Redis: Redis cluster with sharding

Time Investment Requirements

Initial Setup Optimization

• Configuration tuning: 4-8 hours
• Load testing validation: 8-16 hours
• Monitoring setup: 4-8 hours
• Documentation: 2-4 hours

Ongoing Performance Management

• Performance monitoring: 2-4 hours/week
• Capacity planning: 4-8 hours/quarter
• Configuration updates: 1-2 hours/month
• Incident response: 2-8 hours/incident (depending on complexity)

Prerequisites and Dependencies

Technical Requirements

• PostgreSQL expertise: Database tuning, connection pooling
• Redis knowledge: Clustering, memory management
• Load testing tools: K6, Apache Bench, or equivalent
• Monitoring stack: Prometheus, Grafana for metrics collection

Infrastructure Requirements

• Network latency: <5ms between Kong and upstreams for optimal performance
• Storage: SSD storage for database and logs
• DNS: Fast, reliable DNS resolution (use IP addresses when possible)
• Load balancer: Layer 4 load balancer in front of Kong instances

Implementation Checklist

Pre-Production Validation

1. Load test with realistic traffic patterns (burst + sustained)
2. Verify database connection pool usage <80%
3. Confirm upstream connection pooling working
4. Test plugin disable/enable procedures
5. Validate health check intervals don't overwhelm backends
6. Set up P95 latency monitoring
7. Document scaling procedures

Post-Deployment Monitoring

1. P95 request latency trending
2. Database connection pool utilization
3. Memory usage per Kong worker
4. Upstream connection counts
5. Plugin processing times
6. Error rate by plugin and endpoint