In the previous article, we explored the network interaction mechanisms of the GBase 8s SSC cluster. This article will focus on calculating network throughput, analyzing the performance of SSC clusters under different business scenarios, and comparing them with HAC and RHAC clusters.

1. Network Throughput in No-Business Scenarios

In the absence of business operations, the network only transmits heartbeat packets and their ACKs per second, resulting in very low network throughput. Specifically:

(114 + 86) / (1024 * 1024) = 0.2 KB/s

The main node sends packets at 1 packet per second (PPS).

2. Network Throughput in Business Scenarios

Assuming high-performance servers and 400 concurrent operations, the TPCC performance is 1 million tpmC. The packets transmitted on the network are LSN data packets and LSN ACK packets.

If the database is in non-buffered log mode, where each transaction commit sends an LSN data packet from the main node, and the secondary node responds with an LSN ACK packet, the network throughput is:

((126 + 94) * 1000000 / 60) / (1024 * 1024) = 3.5 MB/s

The main node's sending PPS is:

1000000 / 60 = 16666.7

In buffered log mode, assuming the logical log buffer is at its maximum value of 64M, the main node sends LSN data packets only when the buffer is full. During TPCC testing, 200M of logical logs are generated for every 10,000 tpmC. At 1 million tpmC, 20,000M of logical logs are produced, resulting in:

(20000 / 64) * (126 + 94) / 60 / 1024 = 1.12 KB/s

The main node's sending PPS is:

(20000 / 64) / 60 = 5.2 packets/s

These calculations assume ideal conditions. In actual testing environments, other messages, such as 5-second statistics packets and checkpoint-triggered log buffer flushes, also contribute to network traffic. The above values are based on a single SSC secondary node; for N secondary nodes, the values are multiplied by N.

In comparison, HAC and RHAC clusters in the same business scenarios must transmit at least 200 * 100M of logical logs, resulting in a network throughput of at least:

(200 * 100) / 60 = 333.33 MB/s

3. Analysis of Scenarios Where SSC Secondary Nodes Support Updates

In scenarios where SSC secondary nodes support updates, TPCC operations are executed on the SSC secondary nodes. The TPCC testing includes only new order transactions. The involved tables and their typical field lengths are as follows:

The operations involved are as follows:

UPDATE District
INSERT Order
INSERT New-Order
for(int i = 0; i < num; i++) {
    UPDATE Stock
    INSERT Order-Line
}

The new order transaction typically involves 10 order items per customer, i.e., the value of num is 10. Assuming num = 1, the network interaction packets for each transaction between the main and secondary nodes are as follows:

1st Packet:

• SSC secondary node to main node: ProxyWriteBeginWork, ProxyWriteUpdate, and ProxyWriteSync (District table)
• Packet length: 54 + 20 + 176 + (108 + 95 * 2 + 4) + 28 = 580 bytes
• Main node response: ProxyWriteSync, length 54 + 20 + 68 = 142 bytes

2nd Packet:

• SSC secondary node to main node: ProxyWriteInsert and ProxyWriteSync (Order table)
• Packet length: 54 + 20 + (108 + 24 + 4 - 2) + 28 = 236 bytes
• Main node response: ProxyWriteSync, length 54 + 20 + 68 = 142 bytes

3rd Packet:

• SSC secondary node to main node: ProxyWriteInsert and ProxyWriteSync (New-Order table)
• Packet length: 54 + 20 + (108 + 8 + 4 - 2) + 28 = 220 bytes
• Main node response: ProxyWriteSync, length 54 + 20 + 68 = 142 bytes

4th Packet:

• SSC secondary node to main node: ProxyWriteUpdate and ProxyWriteSync (Stock table)
• Packet length: 54 + 20 + (108 + 306 * 2 + 4 - 2) + 28 = 824 bytes
• Main node response: ProxyWriteSync, length 54 + 20 + 68 = 142 bytes

5th Packet:

• SSC secondary node to main node: ProxyWriteInsert and ProxyWriteSync (Order-Line table)
• Packet length: 54 + 20 + (108 + 54 + 4 - 2) + 28 = 266 bytes
• Main node response: ProxyWriteSync, length 54 + 20 + 68 = 142 bytes

6th Packet:

• SSC secondary node to main node: ProxyWriteBeginWork, ProxyWriteFlush2LSN, and ProxyWriteCommit
• Packet length: 54 + 20 + 176 + 36 + 28 = 314 bytes
• Main node response: ProxyWriteSync, length 54 + 20 + 68 = 142 bytes

For num > 1, repeat packets 4 and 5 for num times. Thus, for TPCC testing with only new order transactions at 1 million TPMC, the network traffic per transaction is:

(580 + 142) + (236 + 142) + (220 + 142) + ((824 + 142) + (266 + 142)) * 10 + (314 + 142) = 15658 bytes

Network throughput is:

15658 * 1000000 / 60 / 1024 / 1024 = 248.9 MB/s

SSC secondary node's sending PPS is:

(4 + 2 * 10) * 1000000 / 60 = 400000 packets/s

4. Comparison with HAC and RHAC Clusters

From the above sections, it is evident that in the same business scenarios, SSC clusters have much lower network pressure compared to HAC and RHAC clusters. At 1 million TPMC, SSC clusters' main-to-secondary node network throughput is 3.4 MB/s, with the main node sending PPS at 16666.7 packets/s. HAC and RHAC clusters, however, have network throughput of at least 333.33 MB/s.

Additionally, in scenarios where SSC secondary nodes support updates, assuming TPCC includes only new order transactions, and performance reaches 1 million TPMC, the network throughput is 248.9 MB/s, with SSC secondary nodes sending PPS at 400000 packets/s.

By analyzing the network throughput of GBase 8s SSC clusters, we can see their excellent performance in different business scenarios. The design of SSC clusters not only optimizes network interactions but also ensures stability and reliability under high loads. As enterprises continue to demand higher database performance, GBase 8s SSC clusters will undoubtedly become the first choice for more businesses.