Scaling a Single-Server Topology for Registration Peak

Adding a second identical node improves availability but does not by itself fix the bottleneck. If both nodes run gateway, dispatcher, and Content Manager, gateway traffic still competes with report processing, and both nodes will increase pressure on the already busy content store. The 90% CPU and timeouts indicate application-tier saturation, while the 70% content store CPU indicates a shared database bottleneck that more dispatchers can worsen.

A better target separates roles. Put the gateway on dedicated hosts or at least isolate gateway traffic from report execution. Run two or more dispatcher nodes for the application tier, and decide deliberately where Content Manager runs; do not let every new node become a Content Manager by accident. Size the content store database for the combined load, including connections from all dispatchers, and consider separating the audit database if it shares the same instance. Keep the F5 in front of the gateway tier for availability. Add nodes only after confirming that the database can absorb the extra connection and locking load. The topology should be validated with a load test that reproduces the 1,100-user peak, not just a two-node smoke test.

Use the external load balancer for gateway high availability, with health checks that test an actual Cognos endpoint rather than just a TCP port. Cookie-based persistence is appropriate for interactive users at the gateway layer because it keeps a user's session on a consistent gateway node. Avoid a persistence rule that pins all users to one dispatcher; that recreates the original bottleneck. The gateway-to-dispatcher configuration should use consistent internal and external dispatcher URIs so that redirects and content references remain reachable through the load balancer.

Confirm that the dispatcher routing rules send batch work to the appropriate nodes and that report services are enabled where capacity exists. Test what happens when one dispatcher is stopped: new requests should go to the remaining nodes, and users should not be sent to a dead URI. Also test scheduled jobs during the failover because batch report service routing can differ from interactive routing. Document which URLs are published to users and ensure only the load-balanced gateway URL is exposed; direct dispatcher URLs should not be handed out. Finally, monitor per-node request counts to verify that the load balancer is actually distributing sessions as intended.

Treat the content store as a shared critical service. Before adding dispatchers, capture baseline CPU, memory, disk latency, connection counts, lock waits, and slow queries. The DBA's 70% CPU warning means additional dispatchers may turn a busy database into a failing one. Increase database capacity or tune the content store workload first, and separate audit traffic if audit logging shares the same instance. Review connection pool settings on each dispatcher so that adding nodes does not multiply connections beyond what the database can handle.

For monitoring, track dispatcher queue depth, active requests, JVM heap and garbage collection, report service throughput, and batch queue delays. Set thresholds that trigger action before the registration peak, not after timeouts appear. Stagger the overnight schedules so that batch jobs do not all start at the same time, and verify that the batch report service has enough capacity after the topology change. After the new nodes are live, compare per-node CPU and request distribution against the baseline. If content store CPU rises while dispatcher CPU falls, the next investment is database capacity, not another application server.