Performance Testing Guide
LUStores includes comprehensive performance testing using k6 load testing framework, integrated into the CI/CD pipeline to ensure application performance meets quality standards.
Overview
Performance testing is automatically executed on every push to the main branch, providing continuous performance monitoring and regression detection. The tests validate:
Application Response Times: Health endpoints and core functionality
Authentication Performance: Login/logout flow efficiency
API Endpoint Performance: Public API response time validation
Concurrent User Handling: Multi-user load simulation
Error Rate Monitoring: System stability under load
k6 Load Testing Framework
Test Configuration
Location: performance-tests/load-test.js
Execution Environment: Docker Compose with full application stack
Load Testing Tool: k6 (https://k6.io/)
Test Stages: .. code-block:: javascript
- export const options = {
- stages: [
{ duration: ’30s’, target: 20 }, // Ramp up to 20 users { duration: ‘1m’, target: 20 }, // Stay at 20 users for 1 minute { duration: ’30s’, target: 0 }, // Ramp down to 0 users
], thresholds: {
http_req_duration: [‘p(95)<500’], // 95% of requests under 500ms http_req_failed: [‘rate<0.1’], // Error rate under 10%
},
};
Test Scenarios
- 1. Health Check Performance
Endpoint:
GET /healthExpected Response Time: < 200ms
Purpose: Validate basic application availability and responsiveness
- 2. User Information API
Endpoint:
GET /api/auth/userExpected Response Time: < 300ms
Purpose: Test user authentication and session management performance
Validation: Ensures response contains user data (id, email)
- 3. Authentication Flow Testing
Endpoint:
POST /auth/loginTest Data: Predefined admin credentials
Expected Response Time: < 500ms
Purpose: Validate login performance and response structure
Validation: Successful authentication with user data returned
Performance Thresholds
Response Time Requirements: - Health Endpoint: 95th percentile under 200ms - Authentication API: 95th percentile under 500ms - User Info API: 95th percentile under 300ms - Overall Application: 95th percentile under 500ms
Error Rate Requirements: - Maximum Error Rate: 10% across all endpoints - Authentication Errors: Login failures tracked separately - Health Check Availability: 99%+ success rate required
Concurrent User Limits: - Simultaneous Users: 20 users supported - Peak Load Duration: 1 minute sustained load - Ramp-up Time: 30 seconds gradual increase
CI/CD Integration
Automated Execution
Trigger Conditions:
- Pushes to main branch only
- Successful completion of unit tests and Docker build
- All security scans must pass
Execution Environment: .. code-block:: yaml
# Docker Compose services started for testing - app: Main application server - replit-auth: Authentication service - db: PostgreSQL database - redis: Session storage
Test Execution Flow: 1. k6 Installation: Modern GPG keyring method for Ubuntu 2. Docker Stack Startup: Full application environment 3. Health Check Wait: Wait for service readiness (60s timeout) 4. Load Test Execution: k6 test script execution 5. Results Collection: JSON and summary report generation 6. Artifact Upload: Performance results stored for dashboard
Results and Reporting
Generated Artifacts:
- performance-results.json: Detailed k6 execution data
- performance-summary.json: High-level test summary
- reports/performance/index.html: HTML dashboard report
Dashboard Integration:
Performance results are automatically integrated into the documentation dashboard at:
https://st7ma784.github.io/LUStores/performance/
Report Contents: - Test Execution Summary: Date, environment, configuration - Response Time Metrics: Percentiles, averages, maximums - Error Rate Analysis: Failed requests and error categorization - Threshold Compliance: Pass/fail status for all defined thresholds - Historical Trends: Performance changes over time (when available)
Local Performance Testing
Prerequisites
System Requirements: - Docker and Docker Compose installed - k6 load testing tool - Minimum 4GB RAM for full stack testing
k6 Installation: .. code-block:: bash
# Ubuntu/Debian sudo gpg -k sudo gpg –no-default-keyring –keyring /usr/share/keyrings/k6-archive-keyring.gpg –keyserver hkp://keyserver.ubuntu.com:80 –recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69 echo “deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main” | sudo tee /etc/apt/sources.list.d/k6.list sudo apt-get update sudo apt-get install k6
# macOS brew install k6
# Windows choco install k6
Running Tests Locally
1. Start Application Stack: .. code-block:: bash
# Start all required services docker compose up -d
# Wait for application readiness curl -s http://localhost:5000/health
2. Execute Performance Tests: .. code-block:: bash
# Run k6 load tests k6 run performance-tests/load-test.js
# Run with custom output k6 run performance-tests/load-test.js
–out json=results.json –summary-export=summary.json
3. Analyze Results: .. code-block:: bash
# View test summary cat summary.json | jq .
# Check specific metrics k6 run performance-tests/load-test.js –quiet
Custom Test Scenarios
Creating Custom Tests: .. code-block:: javascript
import { check, group } from ‘k6’; import http from ‘k6/http’;
- export default function () {
- group(‘Custom API Test’, () => {
const response = http.get(${BASE_URL}/api/custom-endpoint);
- check(response, {
‘status is 200’: (r) => r.status === 200, ‘response time < 300ms’: (r) => r.timings.duration < 300, ‘response has data’: (r) => {
const body = JSON.parse(r.body); return body.data && body.data.length > 0;
},
});
});
}
Environment Variables: .. code-block:: bash
# Customize test environment export BASE_URL=http://localhost:3000 # Different port export TEST_DURATION=30s # Shorter test duration export CONCURRENT_USERS=10 # Fewer concurrent users
k6 run performance-tests/load-test.js
Troubleshooting
Common Issues
1. Service Startup Failures .. code-block:: bash
# Check service status docker compose ps
# View service logs docker compose logs app docker compose logs replit-auth
- 2. Authentication Failures
Issue: Login requests returning unexpected status codes
Solution: Verify authentication service is running and accessible
Debug: Check
POST /auth/loginendpoint manually
- 3. High Response Times
Issue: Tests failing due to slow response times
Investigation: Check system resources and database connections
Optimization: Consider database query optimization or caching
- 4. k6 Installation Issues
Ubuntu: Use modern GPG keyring method (not deprecated apt-key)
Permissions: Ensure proper sudo access for package installation
Network: Verify internet access for package downloads
Performance Optimization
Database Optimization: - Index optimization for frequently queried tables - Connection pooling configuration - Query performance analysis
Application Optimization: - Response caching strategies - API response optimization - Static asset optimization
Infrastructure Optimization: - Container resource allocation - Load balancer configuration - CDN implementation for static assets
Performance Monitoring
Continuous Monitoring
CI/CD Integration: - Automated performance regression detection - Historical performance trend analysis - Performance threshold enforcement
Alert Configuration: - Performance degradation alerts - Error rate spike notifications - Service availability monitoring
Metrics Collection: - Response time percentiles (50th, 95th, 99th) - Request rate and throughput - Error rate and error categorization - Resource utilization (CPU, memory, database)
Dashboard Features: - Real-time performance metrics - Historical trend visualization - Comparative analysis across builds - Performance budget tracking
Best Practices
Test Design
- 1. Realistic Load Patterns:
Model actual user behavior patterns
Include realistic think time between requests
Test peak usage scenarios
- 2. Comprehensive Coverage:
Test all critical user journeys
Include both read and write operations
Validate error handling under load
- 3. Environment Consistency:
Use production-like data volumes
Match production configuration settings
Consistent test environment setup
Performance Standards
- 1. Response Time Goals:
Interactive responses: < 200ms
Page loads: < 1 second
API responses: < 500ms
Background operations: < 5 seconds
- 2. Availability Targets:
System availability: 99.9%
Error rate: < 1% under normal load
Error rate: < 10% under stress
- 3. Scalability Requirements:
Support 20+ concurrent users
Graceful degradation under high load
Automatic recovery from temporary failures