Skip to main content
Welcome to Virtru's support portal. As we work to make this page more accessible to screen readers, please contact us at support@virtru.com for technical support.

Virtru Private Keystore (for Virtru Solutions): Reference - Performance and Testing

Craig Engle
  • Updated

On This Page

 

About

Virtru Private Keystore (for Virtru Solutions)

Install

The tool is docker based and must be pulled down in order to perform CKS testing. Currently, the CKS Testing Tool is in a private repository and the user must authenticate.

docker login
docker pull virtru/cks-tool:v1.1.0

Usage

The docker command is expected to run 1 time and terminate after it writes output to the console. The tool constructs a valid request to CKS and uses Apache AB to make the specified number of requests at the specified concurrency level.

Example 1

This example will connect to the cks and run 100000 requests at 100 concurrent requests.

docker run --rm \
virtru/cks-tool:v1.1.0 \
--host=cks.example.com \
--key=XXXXXXX@token.virtru.com \
--secret=XXXXXXXXXXXXXXXXXXXX \
--concurrency=100 \
--requests-number=100000 \
--verify-tls=false

Example 2

This example will connect to the cks and run 100000 requests at 1000 concurrent requests.

docker run --rm \
virtru/cks-tool:v1.1.0 \
--host=cks.example.com \
--key=XXXXXXX@token.virtru.com \
--secret=XXXXXXXXXXXXXXXXXXXX \
--concurrency=100 \
--requests-number=100000 \
--verify-tls=false

Benchmarks

We were able to increase requests per second and utilize the hardware more fully by using multiple CKS docker containers and increasing the number of threads available to HAProxy.

image1.png

Note

  • Intel Xeon E5-2678 has 16 cores.
  • Intel Xeon 8124M has 8 cores.

Conclusion

The ratio that we found provided the highest throughput and the most stable performance under load was to divide the physical cores between HAProxy threads and CKS Docker containers for a physical core at a ratio of 1(Haproxy Thread):3 (CKS Containers). During load testing, the total server CPU utilization should not be above 80% to ensure a stable production system. Anything above 80% utilization may cause a watchdog agent to kill a docker container, process, or connection.

The option tuned were:

  • Haproxy nbproc
    • haproxy.cfg parameter that controls the number of processes spawned when the Haproxy container starts
  • Haproxy nbthread
    • haproxy.cfg parameter that controls the number of threads spawned by each haproxy process (nbproc)
    • Tunable
  • Number of CKS containers
    • haproxy.cfg
    • docker-compose.yml

Recommendations

The optimal performance for the load testing performed was obtained using a ratio of:

  • 1 = nbproc
  • .25 physical core count = nbthread
  • .75 physical core count = number of cks containers

Sample Configurations

These configurations should be validated to ensure the CPU utilization should be at or below 80% during load testing.  The configurations are attached in zip files containing 2 files which can replace their respective file :

  • haproxy.cfg
  • docker-compose.yml

 

Related articles