Performance Issues
This guide covers identifying and resolving performance issues in License Monitor and License Server Detail.
Performance Metrics
Section titled “Performance Metrics”Key Metrics to Monitor
Section titled “Key Metrics to Monitor”| Metric | Healthy Range | Warning | Critical |
|---|---|---|---|
| API Response Time | < 100ms | 100-500ms | > 500ms |
| CPU Usage | < 50% | 50-80% | > 80% |
| Memory Usage | < 70% | 70-90% | > 90% |
| Error Rate | < 1% | 1-5% | > 5% |
| Active Connections | < limit/2 | limit/2-80% | > 80% limit |
Collecting Metrics
Section titled “Collecting Metrics”# API response timecurl -w "Time: %{time_total}s\n" -o /dev/null -s \ http://localhost:8080/api/health
# CPU and memory usageps aux | grep license_monitor | awk '{print "CPU:", $3"%", "MEM:", $4"%"}'
# Connection countss -s | grep TCP
# Detailed metrics endpointcurl http://localhost:8080/api/metricsCPU Performance
Section titled “CPU Performance”High CPU Usage
Section titled “High CPU Usage”Symptoms: License Monitor using excessive CPU, system slowdown.
-
Identify the cause
Terminal window # Check CPU usage over timetop -p $(pgrep license_monitor) -b -n 5# Profile with perf (Linux)perf top -p $(pgrep license_monitor) -
Check polling interval
# Increase if too frequent[command_mode]interval_seconds = 600 # 10 minutes -
Check regex complexity
# Simplify regex patterns[tail_mode]# Instead of complex pattern# regex_pattern = "^(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d+).*"# Use simpler patternregex_pattern = "^\\d{4}" -
Check parse script efficiency
Terminal window # Time the parse scripttime (lmstat -a | python3 parse.py)
CPU Optimization
Section titled “CPU Optimization”# config.toml optimizations[command_mode]interval_seconds = 600 # Reduce polling frequency
[api]max_connections = 50 # Limit concurrent connectionsrate_limit_requests = 60 # Limit request rate
[tail_mode]batch_size = 50 # Process logs in batchesMemory Performance
Section titled “Memory Performance”High Memory Usage
Section titled “High Memory Usage”Symptoms: Memory grows over time, eventual OOM.
-
Check current memory usage
Terminal window # Process memoryps aux | grep license_monitor# Detailed memory mappmap -x $(pgrep license_monitor)# Memory over timewatch -n 5 'ps aux | grep license_monitor | awk "{print \$6/1024\"MB\"}"' -
Check for memory leaks
Terminal window # Monitor RSS growthwhile true; dops -o rss= -p $(pgrep license_monitor)sleep 60done | tee memory.log -
Identify large allocations
- WebSocket connection buffers
- Log message queues
- License data cache
Memory Optimization
Section titled “Memory Optimization”# config.toml memory optimizations[api]max_connections = 50 # Limit connectionsmessage_buffer_size = 100 # Limit buffered messages
[command_mode]cache_ttl_seconds = 300 # Expire cached datamax_cache_entries = 100 # Limit cache size# System-level limits[Service]MemoryMax=512MMemoryHigh=384MNetwork Performance
Section titled “Network Performance”Slow API Responses
Section titled “Slow API Responses”-
Measure response times
Terminal window # Test endpoint latencyfor i in {1..10}; docurl -w "%{time_total}\n" -o /dev/null -s \http://localhost:8080/api/healthdone | awk '{sum+=$1} END {print "Avg:", sum/NR, "s"}' -
Check for network issues
Terminal window # Network latencyping -c 10 license-server# TCP connection statsss -s# Check for dropped packetsnetstat -s | grep -i drop -
Check upstream latency
Terminal window # Time license server querytime lmstat -a -c 27000@license-server
Network Optimization
Section titled “Network Optimization”# config.toml network optimizations[api]read_timeout_seconds = 30 # Request read timeoutwrite_timeout_seconds = 30 # Response write timeoutidle_timeout_seconds = 60 # Idle connection timeout
[command_mode]timeout_seconds = 60 # Command execution timeout# nginx proxy optimizationsupstream license_monitor { server 127.0.0.1:8080; keepalive 32; # Connection pooling}
server { proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_send_timeout 30s;
# Enable compression gzip on; gzip_types application/json;}Database Performance
Section titled “Database Performance”Convex Performance
Section titled “Convex Performance”# Check Convex dashboard for:# - Slow queries# - High function invocation time# - Database size
npx convex dashboardQuery Optimization
Section titled “Query Optimization”// Use indexes for common queriesservers: defineTable({...}) .index("by_active", ["isActive"]) .index("by_vlan", ["vlan"])
// Query with indexconst activeServers = await ctx.db .query("servers") .withIndex("by_active", q => q.eq("isActive", true)) .collect();Load Testing
Section titled “Load Testing”Basic Load Test
Section titled “Basic Load Test”# Using Apache Benchab -n 1000 -c 10 -H "X-API-Key: KEY" \ http://localhost:8080/api/health
# Using wrkwrk -t4 -c100 -d30s -H "X-API-Key: KEY" \ http://localhost:8080/api/health
# Using heyhey -n 1000 -c 10 -H "X-API-Key: KEY" \ http://localhost:8080/api/healthInterpreting Results
Section titled “Interpreting Results”| Metric | Good | Investigate |
|---|---|---|
| Requests/sec | > 1000 | < 100 |
| Avg latency | < 50ms | > 200ms |
| p99 latency | < 200ms | > 1s |
| Error rate | 0% | > 1% |
Performance Tuning Checklist
Section titled “Performance Tuning Checklist”License Monitor
Section titled “License Monitor”- Appropriate polling interval (5-10 minutes)
- Simple regex patterns
- Efficient parse scripts
- Reasonable cache TTL
- Connection limits configured
- Rate limiting enabled
License Server Detail
Section titled “License Server Detail”- Production build (not dev)
- React Query caching enabled
- Lazy loading for heavy components
- Image optimization
- Bundle size optimized
Infrastructure
Section titled “Infrastructure”- Adequate CPU/memory resources
- SSD storage for logs
- Low-latency network to license servers
- CDN for static assets
- Reverse proxy with keepalive
Next Steps
Section titled “Next Steps”- Debugging Guide - Deep debugging
- Log Analysis - Log-based analysis
- Connection Problems - Network issues