Some english fixes from grammarly

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