Google Meet
This section provides the performance summary of the Google Meet service managed through CCKM on the CipherTrust Manager server.
Requests Per Second
The following sections list the wrap requests per second, approximate latency, and the number of virtual users for different deployment scenarios.
Note
To provide a good user experience, Google recommends a maximum latency of 200 ms (for 99% of the requests). Therefore, the performance numbers on this page are based on a latency of around 200 ms.
Google Cloud
Server Location | Client Location |
---|---|
us-central1-a | us-central1-a |
Simulated the wrap
requests for Google Meet on the CipherTrust Manager deployed on Google Cloud Platform using the k6 tool. The following table shows the handled number of requests per second (RPS), with approximate latency, and the number of virtual users for different data samples on a standalone CipherTrust Manager and a two-node CipherTrust Manager cluster connected with a load balancer.
Click a tab to view performance numbers based on two different specifications.
System Volume | Memory | CPUs | NICs |
---|---|---|---|
50 GB | 16 GB | 4 | 1 |
Click a tab to view performance numbers for a standalone CipherTrust Manager or a two-node cluster with a load balancer.
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 20.05 | 17.020454 |
20 | 25.03 | 33.965335 |
30 | 26.66 | 50.521666 |
40 | 35.21 | 66.966574 |
50 | 40.49 | 83.158219 |
60 | 59.01 | 98.682035 |
70 | 97.44 | 111.418039 |
80 | 133.97 | 123.70189 |
90 | 176.21 | 135.2053 |
100 | 228.15 | 144.659485 |
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 30.08 | 16.924155 |
20 | 31.64 | 33.707304 |
30 | 35.04 | 50.19953 |
40 | 32.07 | 65.275485 |
50 | 31.26 | 83.479334 |
60 | 34.3 | 100.113165 |
70 | 34.85 | 116.330861 |
80 | 48.06 | 131.995373 |
90 | 57.27 | 146.40572 |
100 | 48.71 | 165.084861 |
110 | 60.97 | 179.526573 |
120 | 60.65 | 195.083938 |
130 | 77.17 | 208.555295 |
140 | 92.77 | 221.62002 |
150 | 114.61 | 235.661818 |
160 | 149.09 | 246.412045 |
170 | 145.48 | 260.408408 |
180 | 154.93 | 274.462089 |
190 | 214.95 | 279.021415 |
Comparison Graphs
Specification 1: Standalone vs Two-Node Cluster with Load Balancer
System Volume | Memory | CPUs | NICs |
---|---|---|---|
50 GB | 64 GB | 8 | 1 |
Click a tab to view performance numbers for a standalone CipherTrust Manager or a two-node cluster with a load balancer.
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 17.88 | 17.06529 |
20 | 19.73 | 33.744022 |
30 | 21.58 | 50.422754 |
40 | 22.09 | 67.2538575 |
50 | 22.6 | 84.084961 |
60 | 23.285 | 101.1174825 |
70 | 23.97 | 118.150004 |
80 | 25.61 | 134.7643055 |
90 | 27.25 | 151.378607 |
100 | 30.03 | 167.515104 |
110 | 32.81 | 183.651601 |
120 | 40.725 | 199.4530875 |
130 | 48.64 | 215.254574 |
140 | 56.685 | 229.612928 |
150 | 64.73 | 243.971282 |
160 | 93.945 | 254.7707775 |
170 | 123.16 | 265.570273 |
180 | 122.315 | 280.222493 |
190 | 121.47 | 294.874713 |
200 | 140.825 | 304.60713 |
210 | 160.18 | 314.339547 |
220 | 185.175 | 322.6192025 |
230 | 210.17 | 330.898858 |
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 27.17 | 16.953615 |
20 | 27.04 | 33.779457 |
30 | 26.91 | 50.605299 |
40 | 26.165 | 67.53955 |
50 | 25.42 | 84.473801 |
60 | 24.86 | 101.253739 |
70 | 24.3 | 118.033677 |
80 | 23.4 | 134.5760395 |
90 | 22.5 | 151.118402 |
100 | 22.695 | 168.0278065 |
110 | 22.89 | 184.937211 |
120 | 23.045 | 202.25405 |
130 | 23.2 | 219.570889 |
140 | 23.345 | 236.5859305 |
150 | 23.49 | 253.600972 |
160 | 25.035 | 269.5941965 |
170 | 26.58 | 285.587421 |
180 | 28.01 | 302.063464 |
190 | 29.44 | 318.539507 |
200 | 29.16 | 335.178603 |
210 | 28.88 | 351.817699 |
220 | 30.325 | 367.5871685 |
230 | 31.77 | 383.356638 |
240 | 32.265 | 400.296817 |
250 | 32.76 | 417.236996 |
260 | 36.57 | 432.212196 |
270 | 40.38 | 447.187396 |
280 | 40.6 | 463.0674135 |
290 | 40.82 | 478.947431 |
300 | 42.795 | 495.239256 |
310 | 44.77 | 511.531081 |
320 | 48.095 | 526.5320905 |
330 | 51.42 | 541.5331 |
340 | 53.57 | 556.861547 |
350 | 55.72 | 572.189994 |
360 | 59.04 | 586.2393975 |
370 | 62.36 | 600.288801 |
380 | 63.795 | 616.0219505 |
390 | 65.23 | 631.7551 |
400 | 68.685 | 645.9995005 |
410 | 72.14 | 660.243901 |
420 | 91.815 | 668.2584325 |
430 | 111.49 | 676.272964 |
440 | 112.02 | 688.700369 |
450 | 112.55 | 701.127774 |
460 | 113.25 | 716.485093 |
470 | 113.95 | 731.842412 |
480 | 149.03 | 730.723998 |
490 | 184.11 | 729.605584 |
500 | 176.34 | 748.613218 |
510 | 168.57 | 767.620852 |
520 | 230.48 | 755.372963 |
Comparison Graphs
Specification 2: Standalone vs Two-Node Cluster with Load Balancer
AWS Cloud
Server Location | Client Location |
---|---|
us-east-1b | us-central1-a |
Simulated the wrap
requests for Google Meet on the CipherTrust Manager deployed on AWS cloud using the k6 tool. The following table shows the handled number of requests per second (RPS), with approximate latency, and the number of virtual users for different data samples on a standalone CipherTrust Manager and a two-node CipherTrust Manager cluster connected with a load balancer.
Click a tab to view performance numbers based on two different specifications.
System Volume | Memory | CPUs | NICs |
---|---|---|---|
50 GB | 16 GB | 4 | 1 |
Click a tab to view performance numbers for a standalone CipherTrust Manager or a two-node cluster with a load balancer.
=== "Standalone"
Users | Latency (in ms) | Requests/Second
---|---| ---
10 | 40.74 | 16.462869
20 | 41.405 | 32.643829
30 | 42.07 | 48.824789
40 | 42.99 | 64.9318095
50 | 43.91 | 81.03883
60 | 45.02 | 96.9078885
70 | 46.13 | 112.776947
80 | 50.8 | 128.259757
90 | 55.47 | 143.742567
100 | 59.32 | 159.43998
110 | 63.17 | 175.137393
120 | 86.17 | 187.6379445
130 | 109.17 | 200.138496
140 | 132.855 | 212.1405135
150 | 156.54 | 224.142531
160 | 171.395 | 235.5833245
170 | 186.25 | 247.024118
180 | 233.91 | 252.1894955
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 42.72 | 16.175128 |
20 | 42.51 | 32.420987 |
30 | 42.93 | 48.446633 |
40 | 43.01 | 64.355091 |
50 | 42.95 | 80.807762 |
60 | 44.15 | 96.639114 |
70 | 44.19 | 113.047133 |
80 | 44.91 | 128.65812 |
90 | 44.65 | 145.081845 |
100 | 45.73 | 160.505509 |
110 | 46.2 | 176.699848 |
120 | 47.6 | 192.15855 |
130 | 47.89 | 208.666368 |
140 | 48.82 | 223.88651 |
150 | 50.38 | 239.599473 |
160 | 50.71 | 255.035196 |
170 | 53.61 | 271.573122 |
180 | 54.82 | 286.369364 |
190 | 55.49 | 303.581732 |
200 | 56.79 | 318.599251 |
210 | 65.34 | 330.573892 |
220 | 74.42 | 345.847797 |
230 | 77.65 | 360.133676 |
240 | 76.49 | 376.312516 |
250 | 89.46 | 387.2406 |
260 | 100.6 | 401.232406 |
270 | 109.46 | 414.571807 |
280 | 111.26 | 421.506349 |
290 | 146.54 | 433.911498 |
300 | 176.28 | 438.805221 |
310 | 227.25 | 442.49615 |
Comparison Graphs
Specification 1: Standalone vs Two-Node Cluster with Load Balancer
System Volume | Memory | CPUs | NICs |
---|---|---|---|
50 GB | 64 GB | 8 | 1 |
Click a tab to view performance numbers for a standalone CipherTrust Manager or a two-node cluster with a load balancer.
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 37.78 | 16.322682 |
30 | 37.18 | 48.820999 |
50 | 37.3 | 81.370941 |
70 | 37.88 | 113.599354 |
90 | 38 | 146.272925 |
110 | 38.09 | 179.040711 |
130 | 40.53 | 210.124152 |
150 | 39.86 | 243.147436 |
170 | 43.51 | 274.400142 |
190 | 43.16 | 306.649272 |
210 | 63.38 | 336.642994 |
230 | 82.02 | 363.879907 |
250 | 71.4 | 395.708195 |
270 | 76 | 425.888079 |
290 | 89.94 | 452.540139 |
310 | 107.85 | 477.489702 |
330 | 139.12 | 498.423816 |
350 | 135.27 | 526.025136 |
370 | 191.95 | 533.67742 |
390 | 203.22 | 559.302403 |
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 39.08 | 16.436472 |
30 | 38.72 | 48.568014 |
50 | 38.29 | 81.638752 |
70 | 38.39 | 113.121597 |
90 | 38.43 | 145.660924 |
110 | 38.69 | 178.108611 |
130 | 38.75 | 210.357358 |
150 | 38.81 | 242.386283 |
170 | 39.92 | 274.120341 |
190 | 39.02 | 307.585027 |
210 | 39.38 | 339.976054 |
230 | 39.53 | 373.269723 |
250 | 42.06 | 403.133135 |
270 | 40.5 | 435.59251 |
290 | 41 | 467.333349 |
310 | 41.19 | 499.85638 |
330 | 41.66 | 531.694894 |
350 | 42.26 | 563.708383 |
370 | 45.77 | 596.375765 |
390 | 45.41 | 625.913359 |
410 | 49.66 | 655.925265 |
430 | 47.56 | 691.350867 |
450 | 52.85 | 719.563383 |
470 | 50.78 | 753.029761 |
490 | 52.99 | 783.212132 |
510 | 68.15 | 808.508404 |
530 | 93.18 | 826.906719 |
550 | 91.24 | 859.003234 |
570 | 79.32 | 894.770676 |
590 | 80.85 | 921.922404 |
610 | 96.21 | 944.098372 |
630 | 115.56 | 965.814237 |
650 | 103.16 | 996.276651 |
670 | 111.79 | 1013.853819 |
690 | 150.87 | 1020.147071 |
710 | 143.65 | 1056.794036 |
730 | 199.25 | 1048.523167 |
750 | 180.53 | 1085.514714 |
770 | 245.94 | 1059.777624 |
Comparison Graphs
Specification 2: Standalone vs Two-Node Cluster with Load Balancer
Physical Appliance
Server Location | Client Location |
---|---|
San Jose | us-central1-a |
CipherTrust Manager Configuration
System Volume | Memory | CPUs | NICs |
---|---|---|---|
2 TB | 16 GB | 1 with 4 Cores | 1 |
Simulated the wrap
requests for Google Meet on the CipherTrust Manager deployed on a physical appliance using the k6 tool. The following table shows the handled number of requests per second (RPS), with approximate latency, and the number of virtual users for different data sample for three runs.
Users | Latency (in ms) | Requests/Second |
---|---|---|
10 | 67.82 | 15.779881 |
20 | 72.94 | 31.134493 |
30 | 78.06 | 46.489105 |
40 | 96.28 | 61.3374385 |
50 | 114.5 | 76.185772 |
60 | 146.38 | 89.158117 |
70 | 178.26 | 102.130462 |
80 | 181.66 | 115.192588 |
90 | 185.06 | 128.254714 |
100 | 195.665 | 141.931562 |
110 | 206.27 | 155.60841 |
Comparison Graphs
Physical Appliance vs AWS Cloud vs Google Cloud
Recommendations
Note
When an encrypted Google Meet call is started, a wrap
request is initiated. Similarly, when a participant joins the call, an unwrap
request is initiated.
Google Cloud
Response time compliance of around 200 ms was met for a maximum throughput of 144.66 operations per second with a standalone CipherTrust Manager k170v instance with 4 CPUs and 16 GB RAM.
Response time compliance of around 200 ms was met for a maximum throughput of 279.02 operations per second with a two-node CipherTrust Manager k170v cluster (each node with 4 CPUs and 16 GB RAM) connected with a Google Cloud load balancer.
Response time compliance of around 200 ms was met for a maximum throughput of 330.899 operations per second with a standalone CipherTrust Manager k470v instance with 8 CPUs and 64 GB RAM.
Response time compliance of around 200 ms was met for a maximum throughput of 755.37 operations per second with a two-node CipherTrust Manager k470v cluster (each node with 8 CPUs and 64 GB RAM) connected with a Google Cloud load balancer.
AWS Cloud
Response time compliance of around 200 ms was met for a maximum throughput of 252.19 operations per second with a standalone CipherTrust Manager k170v instance with 4 CPUs and 16 GB RAM.
Response time compliance of around 200 ms was met for a maximum throughput of 442.50 operations per second with a two-node CipherTrust Manager k170v cluster (each node with 4 CPUs and 16 GB RAM) connected with an AWS load balancer.
Response time compliance of around 200 ms was met for a maximum throughput of 559.30 operations per second with a standalone CipherTrust Manager k470v instance with 8 CPUs and 64 GB RAM.
Response time compliance of around 200 ms was met for a maximum throughput of 1059.78 operations per second with a two-node CipherTrust Manager k470v cluster (each node with 8 CPUs and 64 GB RAM) connected with an AWS load balancer.
Conclusion
The number of users and throughput almost doubles up on moving from CipherTrust Manager k170v to k470v. Moreover, adding an additional node to the cluster also doubles up the throughput. Overall, a performance gain of 400 percent is achieved by moving from a standalone CipherTrust Manager k170v to a two-node CipherTrust Manager k470v cluster.