Deuxfleurs
/
garagehq.deuxfleurs.fr
26
2
Fork 1
Code Issues 5 Pull Requests 3 Projects Releases Wiki Activity

Some english fixes from grammarly

This commit is contained in:
maximilien 2022-09-29 08:51:12 +02:00
parent 6ee5ef82ad
commit 990dd55948
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
content/blog/2022-perf/index.md
View File

@ -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