Fletcher Load Testing Results

Test Environment

Test Configuration: 300 users, single run mode

Limitations: PostgreSQL connection pool becomes the primary bottleneck.

MAX_CONNECTIONS: 10 (default)
Fletcher Memory Usage: 275MB
- Increased memory due to request queuing while waiting for database responses
- More PostgreSQL connections reduce Fletcher's memory pressure by pushing load to the database
Fletcher CPU Usage: 13% of 1 core
Performance Characteristics:
- Optimal Performance Threshold: 950 concurrent users
- Peak Requests/Second: 140 (without performance degradation)
- Failure Threshold: 2,500+ users (10s median response time)
- Primary Bottleneck: PostgreSQL CPU utilization

Improvements: Increased connection pool reduces database bottleneck.

MAX_CONNECTIONS: 30 (3x increase)
Fletcher Memory Usage: 160MB (42% reduction)
Fletcher CPU Usage: 20% of 1 core
Performance Characteristics:
- Optimal Performance Threshold: 1,300 concurrent users (+37% improvement)
- Peak Requests/Second: 180 (+29% improvement)
- Failure Threshold: 2,500+ users (8s median response time)
- Primary Bottleneck: PostgreSQL CPU utilization

Metric	10 Connections	30 Connections	Improvement
Optimal Users	950	1,300	+37%
Peak RPS	140	180	+29%
Fletcher Memory	275MB	160MB	-42%
Fletcher CPU	13%	20%	+54%

Database-Bound Performance: PostgreSQL CPU utilization is the primary limiting factor across all test configurations
Connection Pool Impact: Increasing PostgreSQL connections from 10 to 30 provides significant but diminishing returns
Memory Efficiency: Higher connection counts reduce Fletcher's memory pressure by distributing load to the database
Scalability Ceiling: Even with optimal configuration, performance plateaus due to database constraints

Transaction Safety: Using connection pooling with transactions maintains data integrity under load
Raw Connection Trade-offs: While raw PostgreSQL connections could theoretically improve performance, they introduce unacceptable data integrity risks during high-load scenarios

Production Configuration: Use MAX_CONNECTIONS=30 for optimal performance
Capacity Planning: Plan for ~1,000-1,300 concurrent users with current architecture
Monitoring: Focus on PostgreSQL CPU and connection utilization as key metrics
Future Optimization: Consider database resource scaling for higher loads

Tool: Locust load testing framework
Scenarios: Realistic Fletcher API workflows (authentication, plan creation, state updates)
Measurement: Response times, error rates, resource utilization
Environment: Local PostgreSQL instance for maximum performance baseline

Comprehensive interactive reports with detailed charts and statistics:

Stress Test (30 Connections)
- Optimized configuration with 1,300 user capacity
Stress Test (10 Connections)
- Default configuration with 950 user capacity
Busiest Day Test
- Production load simulation (300 users, 8m3s runtime)

Request rate visualizations over time:

30 Connections: Optimal configuration achieving 180 RPS with 1,300 user capacity

10 Connections: Default configuration achieving 140 RPS with 950 user capacity

Busiest Day: 300 users representing peak daily load (8m3s runtime)

CSV files with detailed request logs for analysis: