Following two scenarios have been tested using the above methodology:

• Scale out test – Maximum number of pods in the cluster.
• Scale up test – Increasing the CPU/memory resources of the pods in the cluster.

More information is available in the best practices section to tune the pods and SQL Server for the above tests.

Scale out test

The objective of this test is to check the scale out performance of the SQL Server pods across the OCP cluster. Four pods containing 16 CPUs per pod are deployed on each node scaling to 32 (eight nodes * four pods per node) pods across eight worker nodes maximizing the compute capacity of the worker nodes. Thirty-two HammerDB instances generate the OLTP load simultaneously by running the Benchmark. One to one mapping is considered between HammerDB instance and SQL pods to simulate a real-life client/server scenario.

The following graph shows the TPM performance for 32 pods running on an OpenShift cluster containing three control plane and eight worker nodes:

Figure 6.   Scale out test graph

As seen from the above test results, approximately 8.2 million TPMs are achieved with sub millisecond read and write latency.

Scale up test

This test focuses on scaling up SQL Server pods with high CPU resources. Two pods containing 32 CPUs per pod are deployed across each node. A total of 16 (eight nodes * two pods per node) pods are deployed across eight worker nodes maximizing the available compute capacity. Sixteen HammerDB instances generate the OLTP workload simultaneously. SQL Server pods and HammerDB instances are mapped in a 1:1 ratio depicting a client/server scenario.

The following chart shows the TPM performance for 16 pods of 32 CPUs each on an OpenShift cluster containing three control plane and eight worker nodes:

Figure 7.   Scale up test graph

As seen from the above test results, the maximum transactions achieved are 7.5 million TPMs under sub millisecond read and write latency.