Performance, scalability and capacity management
Measure before scaling
Capacity work starts with Performance Monitoring (PM), LifeTime Environment Health, and Service Center logs. Track response time by screen and integration, slow queries, error rate, timer duration, and concurrent users. PM thresholds make slow transactions visible; without them you are guessing.
Scaling rules
- Scale front-ends horizontally behind a load balancer for web throughput and resilience.
- Treat the database as the usual bottleneck: tune slow queries and indexes before adding front-ends.
- Cache reference data and avoid chatty integrations; measure the effect in PM, not by intuition.
- Run timers and integrations with appropriate concurrency; a single long timer can starve other work.
- Load-test in a Production-like environment with realistic data volumes and think time.
Worked example
A dashboard screen breaches its SLA at month-end. PM shows 85% of time in one SQL query; front-end CPU is low. You add a covering index and rewrite the query to avoid a full scan, then re-run the load test. Reasoning: the bottleneck is database work, so adding front-ends would only increase contention. After the fix, PM confirms the query time dropped and the screen meets its threshold.
Traps
- Adding front-end servers when the database is saturated.
- Testing only in Development with tiny data sets.
- Ignoring timers and integrations because they are not user-facing.
- Leaving PM thresholds unset and discovering slowness only from users.
- Scaling without checking cache invalidation and session behavior across front-ends.