---
title: Load Tests
sidebar_label: Load Tests
---

## Summary
This document includes performance test results of Kubernetes API using various vCluster and K8s distributions and configurations.
This is a TL;DR of the test results, the detailed results can be found below. During our tests, K3s with SQLite lagged behind other distributions when running high intensity loads. However, for less intensive usage and a more simple deployment, it was only marginally slower than the others while staying well within the usable range.
If you plan on having high api usage in your vClusters, we recommend using an etcd backed distribution as you will most likely experience timeouts or throttling with the sqlite backed distribution. For less intense usage, K3s with SQLite will be as adequate as the others.


## API Response Times

<figure>
  <img src="/docs/v0.19/media/apiserver-latency-baseline.svg" alt="apiserver-avg-baseline" />
  <figcaption>APIserver average response time (baseline)</figcaption>
</figure>

During our baseline testing (300 secrets, 30qps), K3s with SQLite was significantly slower than the other distributions, with an average of 0.17s while the other distributions were all around 0.05s. This however should not have an impact since 0.17 is still a relatively good average.


<figure>
  <img src="/docs/v0.19/media/apiserver-latency-intensive.svg" alt="apiserver-avg-intensive" />
  <figcaption>APIserver average response time (intensive)</figcaption>
</figure>

For our more intensive testing (5000 secrets, 200qps), the differences between the distributions are more pronounced, where K3s with SQLite trailed behind with a 1.4s average response time while etcd K3s (vCluster.Pro distro) had an average response time of around 0.35s for both single node and HA setups. k0s and K8s were the fastest in these tests with an average of around 0.15s. Below is also the cumulative distribution of request times.


<figure>
  <img src="/docs/v0.19/media/cumu-distribution-apiserver.svg" alt="apiserver-cumu-dist-intensive" />
  <figcaption>Cumulative distribution of request time during the intensive testing</figcaption>
</figure>

## CPU usage

During our testing, most distributions had similar CPU usage, with the exception of k3s with SQLite which had a higher CPU usage, most likely due to having to convert etcd requests into SQLite ones.

<figure>
  <img src="/docs/v0.19/media/cpu-sn-baseline.svg" alt="cpu usage (baseline)" />
  <figcaption>CPU usage during the baseline test</figcaption>
</figure>

<figure>
  <img src="/docs/v0.19/media/cpu-sn-intensive.svg" alt="cpu usage (intensive)" />
  <figcaption>CPU usage during the intensive test</figcaption>
</figure>

<figure>
  <img src="/docs/v0.19/media/cpu-intensive-ha.svg" alt="cpu usage (intensive) for ha setups" />
  <figcaption>CPU usage during the intensive test (ha setups)</figcaption>
</figure>

## Memory usage

Memory usage was relatively similar in all setups

<figure>
  <img src="/docs/v0.19/media/mem-usage-baseline.svg" alt="memory usage over time sn setup" />
  <figcaption>Memory usage during the baseline test</figcaption>
</figure>

<figure>
  <img src="/docs/v0.19/media/mem-usage-intensive.svg" alt="memory usage over time sn setup" />
  <figcaption>Memory usage during the intensive test</figcaption>
</figure>

<figure>
  <img src="/docs/v0.19/media/mem-usage-ha.svg" alt="memory usage over time ha setup" />
  <figcaption>Memory usage during the intensive test with HA setups</figcaption>
</figure>

## Filesystem use

The filesystem usage was higher in the k3s SQLite version compared to all etcd backed versions in the intensive setup. In the baseline setup there was little to no usage of the filesystem

<figure>
  <img src="/docs/v0.19/media/fs-write-intensive.svg" alt="fs usage over time" />
  <figcaption>Filesystem writes over time</figcaption>
</figure>
<figure>
  <img src="/docs/v0.19/media/fs-read-intensive.svg" alt="memory usage over time sn setup" />
  <figcaption>Filesystem reads over time</figcaption>
</figure>

## Pod latency

kube-burner calculates some statistics on pods, however it uses the status of the pods which only has a precision of seconds. With this level of precision, all distributions had similar p50, p99, average and max values for containerReady, Initialized, podScheduled and Ready.
