diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/blog/2022-perf/index.md | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/content/blog/2022-perf/index.md b/content/blog/2022-perf/index.md index a9dd598..a242154 100644 --- a/content/blog/2022-perf/index.md +++ b/content/blog/2022-perf/index.md @@ -22,7 +22,7 @@ reflecting the high-level properties we are seeking.* ## ⚠️ Disclaimer The results presented in this blog post must be taken with a critical grain of salt due to some -limitations that are inherent to any benchmarking endeavour. We try to reference them as +limitations that are inherent to any benchmarking endeavor. We try to reference them as exhaustively as possible in this first section, but other limitations might exist. Most of our tests were made on simulated networks, which by definition cannot represent all the @@ -36,7 +36,7 @@ For some benchmarks, we used Minio as a reference. It must be noted that we did not try to optimize its configuration as we have done for Garage, and more generally, we have way less knowledge on Minio than on Garage, which can lead to underrated performance measurements for Minio. It must also be noted that -Garage and Minio are systems with different feature sets. For instance Minio supports +Garage and Minio are systems with different feature sets. For instance, Minio supports erasure coding for higher data density, which Garage doesn't, Minio implements way more S3 endpoints than Garage, etc. Such features necessarily have a cost that you must keep in mind when reading the plots we will present. You should consider @@ -83,7 +83,7 @@ needs[^ref1]. Most of the following tests were thus run locally with `mknet` on single computer: a Dell Inspiron 27" 7775 AIO, with a Ryzen 5 1400, 16GB of RAM, a 512GB SSD. In terms of software, NixOS 22.05 with the 5.15.50 kernel is used with an ext4 encrypted filesystem. The `vm.dirty_background_ratio` and -`vm.dirty_ratio` have been reduced to `2` and `1` respectively as, with default +`vm.dirty_ratio` has been reduced to `2` and `1` respectively as, with default values, the system tends to freeze when it is under heavy I/O load. ## Efficient I/O @@ -96,12 +96,12 @@ before receiving it completely, we will evaluate the time-to-first-byte (TTFB) on GetObject requests, i.e. the duration between the moment a request is sent and the moment where the first bytes of the returned object are received by the client. Second, we will evaluate generic throughput, to understand how well -Garage can leverage the underlying machine's performances. +Garage can leverage the underlying machine's performance. **Time-to-First-Byte** - One specificity of Garage is that we implemented S3 web endpoints, with the idea to make it a platform of choice to publish static websites. When publishing a website, TTFB can be directly observed -by the end user, as it will impact the perceived reactivity of the websites. +by the end user, as it will impact the perceived reactivity of the website. Up to version 0.7.3, time-to-first-byte on Garage used to be relatively high. This can be explained by the fact that Garage was not able to handle data internally @@ -313,7 +313,7 @@ the internals of both Minio and Garage**. Minio has no metadata engine, it stores its objects directly on the filesystem. Sending 1 million objects on Minio results in creating one million inodes on the storage server in our current setup. So the performances of the filesystem -probably have substantial impact on the results we observe. +probably have a substantial impact on the results we observe. In our precise setup, we know that the filesystem we used is not adapted at all for Minio (encryption layer, fixed number of inodes, etc.). Additionally, we mentioned earlier that we deactivated @@ -440,7 +440,7 @@ have an impact on performance. Theoretically, our protocol, which is inspired by hash tables (DHT), should scale fairly well, but until now, we never took the time to test it with a hundred nodes or more. -This test was ran directly on Grid5000 with 6 physical servers spread +This test was run directly on Grid5000 with 6 physical servers spread in 3 locations in France: Lyon, Rennes, and Nantes. On each server, we ran up to 65 instances of Garage simultaneously, for a total of 390 nodes. The network between physical servers is the dedicated network provided by @@ -476,7 +476,7 @@ improvement margin. At the same time, Garage has never been in better shape: its next version (version 0.8) will see drastic improvements in terms of performance and reliability. We are confident that Garage is already able to cover a wide range of deployment needs, up -to a over a hundred nodes and millions of objects. +to over a hundred nodes and millions of objects. In the future, on the performance aspect, we would like to evaluate the impact of introducing an SRPT scheduler |