Examine real-world scaling scenarios about qujata HOT 1 OPEN

Design notes with @yeudit - Concurrency input and scalability

• General idea: We would like to take into account the user input "Concurrency" which will specify how many concurrent users (or clients) we'd like to simulate.
  To achieve concurrency for the specified use cases, we need to scale up our K8S running on Azure (AKS).
• Environment: We will run our experiments on a Linux based AKS, with a predefined number of nodes.
  Each node increases the number of concurrency that we can achieve.
  We may use all nodes in the cluster to maximize the concurrency. In some cases, when the desired concurrency is low, we will not need to use all nodes (see dashed line), which will simulate a use case of small-medium traffic applications.
  

Important to know:

• Concurrency depends on the underlying CPU specs.
• Concurrency will not be improved when creating new pods in the same node, if the existing ones already take up the max capacity of the node's CPU cores.
• Concurrency will be improved when adding nodes in the K8S cluster. Adding more nodes = more CPU cores.

Design decisions made:

• When using Docker we will currently support 1 Curl container and 1 NGINX container only.
• When using Kubernetes, for operational simplicity, we deploy Curl pods as a DaemonSet, one per node. The Curl pod that shares the same node with the NGINX pod won't be in use.
• When the app is initiating, we need to calculate the max concurrency of the environment we are running on:

1. Run 10000 (configurable) iterations with algorithm prime256v1 (configurable) on a pod/docker container.
2. Max concurrency = Iteration / Total run time

Research question:

• When NGINX pods increase due to significant traffic, what will happen to the memory and cpu? when using PQC / hybrid algorithms, will we see a faster increase of pods?
• What will be the throughput values when using PQC/hybrid algorithms?

from qujata.