Performance Guide
Tuning and diagnosing performance for your server size. For the underlying config keys (cache-size, cache-expiration, pool-size, etc.), see Performance Configuration.
Sizing Recommendationsโ
| Server size | Database | Cache size | Notes |
|---|---|---|---|
| Small (<50 players) | SQLite | 100 (default) | No optimization needed |
| Medium (50-200) | SQLite | 200-300 | Monitor DB file size, consider periodic cleanup of old orders |
| Large (200+) | MySQL | 500+ (monitor memory) | Use a dedicated DB server, tune pool-size, optimize order expiration |
Async database operations are always on - no configuration needed, no thread blocking.
GUI tuning: gui.update-interval (ticks) - 10-15 for fast updates at the cost of more load, 20 (default) balanced, 40-60 for less frequent but cheaper updates. gui.orders-per-page - lower loads faster, higher shows more orders; default (45) fits most servers.
Key Metrics to Monitorโ
Order creation rate, delivery completion rate, average order value, database size, cache hit rate.
Healthy: commands respond <1s, GUI opens instantly, no TPS impact, fast queries. Unhealthy: commands >2s, GUI lag, TPS drops during order activity, slow queries.
Troubleshootingโ
| Symptom | Check | Fix |
|---|---|---|
| Slow commands | Database performance, cache effectiveness, server CPU/RAM, other plugins | Switch to MySQL, increase cache size, optimize database, free up server resources |
| High memory usage | Cache size too large, too many cached orders, connection pool size | Reduce cache size, reduce cache expiration, optimize queries |
| Database locking | Multiple server instances, file permissions, concurrent ops | Ensure single instance, check file permissions, use MySQL for multi-server setups |
Start with defaults, monitor before optimizing, change one thing at a time, move to MySQL when you actually outgrow SQLite.