Google Calendar

This section provides the performance summary of the Google Calendar 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.

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

• AWS Cloud

• Physical Appliance

Google Cloud

Server Location	Client Location
us-central1-a	us-central1-a

Simulated the wrap requests for Google Calendar 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.

AWS Cloud

Server Location	Client Location
us-east-1b	us-central1-a

Simulated the wrap requests for Google Calendar 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.

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 Calendar 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	73.32	15.662693
20	80.05	30.946652
30	86.78	46.230611
40	91.375	61.377163
50	95.97	76.523715
60	127.28	89.6552465
70	158.59	102.786778
80	183.955	115.7833845
90	209.32	128.779991

Comparison Graphs

Physical Appliance vs AWS Cloud vs Google Cloud

---

Recommendations

Assumption

Each user has 3 documents open and is editing them resulting in an autosave every 30 seconds, that is, 3/30=0.1 transactions per second (tps) per user.

Number of users = (throughput for around 200 ms latency)/0.1

Google Cloud

1. Response time compliance of around 200 ms was met for a maximum throughput of 131.69 operations per second with a standalone CipherTrust Manager k170v instance with 4 CPUs and 16 GB RAM.

   The approximate number of users this configuration can handle is 1317.

2. Response time compliance of around 200 ms was met for a maximum throughput of 252.45 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.

   The approximate number of users this configuration can handle is 2525.

3. Response time compliance of around 200 ms was met for a maximum throughput of 415.02 operations per second with a standalone CipherTrust Manager k470v instance with 8 CPUs and 64 GB RAM.

   The approximate number of users this configuration can handle is 4150.

4. Response time compliance of around 200 ms was met for a maximum throughput of 749.70 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.

   The approximate number of users this configuration can handle is 7497.

AWS Cloud

1. Response time compliance of around 200 ms was met for a maximum throughput of 242.47 operations per second with a standalone CipherTrust Manager k170v instance with 4 CPUs and 16 GB RAM.

   The approximate number of users this configuration can handle is 2425.

2. Response time compliance of around 200 ms was met for a maximum throughput of 455.05 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.

   The approximate number of users this configuration can handle is 4551.

3. Response time compliance of around 200 ms was met for a maximum throughput of 524.96 operations per second with a standalone CipherTrust Manager k470v instance with 8 CPUs and 64 GB RAM.

   The approximate number of users this configuration can handle is 5250.

4. Response time compliance of around 200 ms was met for a maximum throughput of 968.94 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.

   The approximate number of users this configuration can handle is 9689.

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.