Sizing an App Server Tier After a Failed Pilot Benchmark
A company runs SAP S/4HANA on-premises with a productive database of 2.4 TB and a peak application server load of 11,000 SAPS distributed across six application servers. They migrate the database to an Azure M-series VM and want to consolidate the application tier onto four Dsv5 VMs. During a two-week pilot, the four Dsv5 VMs show average CPU utilization of 62 percent but CPU ready time spikes to 18 percent during the month-end close batch, and dialog response time degrades from 0.4 s to 1.9 s. The network team reports that all four VMs and the database VM sit in the same subnet and that the database VM has Accelerated Networking disabled. The customer insists the problem is insufficient vCPU per application server and asks to double the core count.
1. The customer wants to double the vCPU count on each application server. Evaluate whether this addresses the observed symptom, and recommend a diagnostic and remediation sequence.
Read the worked answer
Doubling vCPUs is unlikely to fix the problem and may make it worse. The signature here is not raw CPU saturation: average utilization of 62 percent with a 1.9 s dialog response time points to latency and contention, not throughput exhaustion. CPU ready time of 18 percent means vCPUs are waiting for physical cores, which is a host-level or sizing-of-the-host problem, and it is aggravated when many vCPUs are packed onto a host or when the VM size crosses NUMA boundaries.
The sequence should be:
- Confirm whether the Dsv5 VMs are constrained by the host. Check CPU ready per vCPU, steal time, and whether the VM size spans NUMA nodes. SAP workloads are sensitive to NUMA; a VM whose vCPU count exceeds a single NUMA node without proper configuration will show exactly this pattern.
- Enable Accelerated Networking on the database VM. SR-IOV reduces latency and jitter on the chatty dialog-to-database path, which matters far more for dialog response time than extra application cores.
- Separate the application and database traffic into distinct subnets with network security group rules, so that backup, storage replication, and management traffic cannot contend with dialog traffic.
- Re-benchmark with the SAP standard application benchmark or a representative dialog trace before changing VM sizes.
Only after these steps should sizing be revisited. If CPU ready remains high with modest utilization, the correct move is to change the VM family or reduce vCPU density per host, not simply to add cores. Adding cores to a NUMA-misaligned VM typically increases ready time and worsens response time.
2. The customer also proposes moving all four application servers into an availability set to improve performance. Assess this proposal.
Read the worked answer
An availability set does not improve performance. Its purpose is to distribute VMs across fault domains and update domains so that a host failure or platform maintenance does not take down every instance simultaneously. Placing the application servers in an availability set is still good practice for availability, but it will not reduce CPU ready time or dialog latency, and the customer should be told so plainly.
There is a secondary consideration: availability sets constrain placement, and placement affects which physical hosts the VMs land on. In some cases a poorly chosen availability set configuration can concentrate VMs on a subset of hardware, but that is an unintended side effect, not a performance feature. For SAP application servers that are stateless and behind a load balancer, an availability set or an availability zone spread is the right resilience pattern, and the performance work should proceed independently.
Recommendation: accept the availability set for resilience, but frame it as an HA control, and keep the performance remediation focused on Accelerated Networking, NUMA alignment, subnet separation, and host-level contention analysis.