Performance Summary
This section provides metrics and results of Azure performance testing.
Test Setup
| Test Runner | |
|---|---|
| Operating System | Ubuntu 20.4 |
| RAM | 32GB |
| Core | 16 |
| Appliance | |
|---|---|
| Build | 2.8.0.7157 |
| RAM | 16GB |
Process
Scripts are written on top of the Locust Framework for load and stress testing. The testing is done for create, read, update, and delete (CRUD) key operations with respect to different numbers of virtual users (VUS) over parallel connections, one for every virtual user.
The testing also done to determine the response for uploading keys by a number (N) of virtual users in time (T).
CRUD Operations
Expand the headings below to view performance numbers.
Time taken per key upload with respect to virtual users
| Virutal Users | Minimum | Average | Maximum |
|---|---|---|---|
| 10 | 2.971 | 6.911 | 11.698 |
| 30 | 5.672 | 18.155 | 27.679 |
| 50 | 6.714 | 22.403 | 38.941 |
In the graph above:
X-axis represents the increment of virtual users.
Y-axis represents the time taken by a virtual user to perform BYOK operations.
3 line graphs display information for minimum (min), average (avg), and maximum (max) time taken by one of the virtual users running at that time.
Response with request coverage in percentile (10 VUS, 180 seconds)
| X% percentile | create_byok | get | update | soft-delete | hard-delete | delete-backup |
|---|---|---|---|---|---|---|
| 50 | 6 | 0.36 | 8 | 9.7 | 5.7 | 4.2 |
| 60 | 6.2 | 0.41 | 8.7 | 10 | 7.6 | 4.3 |
| 70 | 6.5 | 0.55 | 9.3 | 10 | 8.9 | 4.4 |
| 80 | 6.6 | 0.63 | 10 | 11 | 10 | 4.5 |
| 90 | 7.1 | 0.82 | 11 | 12 | 11 | 5.7 |
| 100 | 7.7 | 1.3 | 12 | 12 | 6.7 |
Here, X% percentile indicates that X percent requests are completed before this time.
In the graph above:
X-axis represents X% (percentile) of request time. It means, X% requests have taken time less than or equal to Y-axis value at X%.
Y-axis represents the time taken by a virtual user to perform any CRUD operation.
An individual virtual user has performed these CRUD operations sequentially, whereas all the virtual users are spawned in parallel.
Response with request coverage in percentile (30 VUS, 180 seconds)
| X% percentile | create_byok | get | update | soft-delete | hard-delete | delete-backup |
|---|---|---|---|---|---|---|
| 50 | 18 | 0.4 | 22 | 23 | 21 | 16 |
| 60 | 23 | 0.44 | 24 | 25 | 23 | 17 |
| 70 | 26 | 0.48 | 26 | 26 | 23 | 18 |
| 80 | 27 | 0.56 | 26 | 27 | 23 | 20 |
| 90 | 27 | 0.8 | 27 | 27 | 23 | 21 |
| 100 | 28 | 1.3 | 29 | 28 | 23 | 23 |
Here, X% percentile indicates that X percent requests are completed before this time.
In the graph above:
X-axis represents X% (percentile) of request time. It means, X% requests have taken time less than or equal to Y-axis value at X%.
Y-axis represents the time taken by a virtual user to perform any CRUD operation.
An individual virtual user has performed these CRUD operations sequentially, whereas all the virtual users are spawned in parallel.
trepresents time taken for a key operation whenNvirtual users are running in parallel.
Response with request coverage in percentile (50 VUS, 180 seconds)
| X% percentile | create_byok | get | update | soft-delete | hard-delete | delete-backup |
|---|---|---|---|---|---|---|
| 50 | 24 | 0.43 | 39 | 38 | 34 | 33 |
| 60 | 29 | 0.55 | 40 | 38 | 35 | 34 |
| 70 | 31 | 0.69 | 40 | 38 | 35 | 35 |
| 80 | 34 | 0.78 | 41 | 38 | 35 | 35 |
| 90 | 37 | 0.99 | 41 | 39 | 35 | 35 |
| 100 | 39 | 1.4 | 43 | 41 | 36 | 35 |
Here, X% percentile indicates that X percent requests are completed before this time.
In the graph above:
X-axis represents X% (percentile) of request time. It means, X% requests have taken time less than or equal to Y-axis value at X%.
Y-axis represents the time taken by a virtual user to perform any CRUD operation.
An individual virtual user has performed these CRUD operations sequentially, whereas all the virtual users are spawned in parallel.
trepresents time taken for a key operation whenNvirtual users are running in parallel.
Key Upload
This section provides performance numbers for uploading keys by a number (N) of virtual users in time (T).
Expand the headings below to view performance numbers.
Number of keys uploaded by virtual users in 100 seconds
| Virtual Users | Number of Keys |
|---|---|
| 10 | 135 |
| 30 | 130 |
| 50 | 116 |
The graph above shows the number of keys uploaded in t time when N virtual users are spawned in parallel. Also, it indicates throtlling condition breakpoints and helps you calculate throughput per second (TPS).
Response for upload with percentile request coverage
| X% percentile | 10 VUS | 30 VUS | 50 VUS |
|---|---|---|---|
| 50 | 5.9 | 21 | 37 |
| 60 | 6.3 | 23 | 38 |
| 70 | 7.5 | 25 | 38 |
| 80 | 9.2 | 25 | 38 |
| 90 | 11 | 28 | 39 |
| 100 | 12 | 28 | 42 |
In the graph above:
X-axis represents X% (percentile) of request time. It means, X% requests have taken time less than or equal to Y-axis value at X%.
Y-axis represents the time taken by a virtual user to perform the BYOK (upload key) operation.
While calculating TPS, Locust informs about the time taken to complete X% requests when all the virtual users are spawned in parallel.
The number of virtual users does not significantly affect the number of keys being uploaded. This proves the rate limit implemented by Azure side causes throttling.
