Scaling

Scaling BlueSentinel for 50+ devices — performance tuning and architecture.

Scaling Considerations

BlueSentinel is designed to scale to 1000+ devices on a single server with proper tuning.

Database Tuning

PostgreSQL Configuration

For 500+ devices, adjust postgresql.conf:

max_connections = 200
shared_buffers = 1GB
effective_cache_size = 3GB
work_mem = 16MB
maintenance_work_mem = 256MB

Alert Table Management

The alerts table grows fastest. Consider:

  • Partitioning by month using PostgreSQL native partitioning
  • Archival of alerts older than 90 days
  • Vacuuming schedule for large tables

Application Scaling

Gunicorn Workers

Rule of thumb: workers = 2 * CPU cores + 1

bash
gunicorn -w 9 -b 0.0.0.0:5100 "central_server.app:create_app()"

Connection Pool

The default pool size is 10. For 500+ devices hitting the heartbeat endpoint every 60 seconds, increase to 20-30:

python
# In create_app()
app.config['SQLALCHEMY_POOL_SIZE'] = 25
app.config['SQLALCHEMY_MAX_OVERFLOW'] = 10

Monitoring

Key metrics to watch:

  • Heartbeat latency — Time for agents to complete a heartbeat cycle
  • Alert ingestion rate — Alerts per minute
  • Database connections — Active vs idle connections
  • Disk usage — Alert storage growth rate
  • CPU/RAM — Server resource utilization