content/blog/2022-perf/index.md

@@ -4,7 +4,7 @@ date=2022-09-26
 +++
 
 
-*For the past years, we have extensively analyzed possible design decisions and their theoretical tradeoffs on Garage, being it on the network, data structure, or scheduling side. And it worked well enough for our production cluster at Deuxfleurs, but we also knew that people started discovering some unexpected behaviors. We thus started a round of benchmark and performance measurement to see how Garage behaves compared to our expectations.*
+*For the past years, we have extensively analyzed possible design decisions and their theoretical tradeoffs on Garage, being it on the network, data structure, or scheduling side. And it worked well enough for our production cluster at Deuxfleurs, but we also knew that people started discovering some unexpected behaviors. We thus started a round of benchmark and performance measurement to see how Garage behaves compared to our expectations. We split them in 3 categories: "efficient I/O", "myriads of objects" and "resiliency" to reflect the high level properties we are seeking.*
 
 <!-- more -->
 
@@ -152,16 +152,18 @@ By looking at the server resource usage, we saw that their load started to becom
 For now, we are confident that a Garage cluster with 100+ nodes should definitely work. 
 
 
-## Future work
+## Conclusion and Future work
+
+Identified some sensitive points: fsync, metadata engine, raw i/o.
+At the same time, validated important performance improvements (ttfb, minio warp, metadata engine - including less resource usage) while keeping our versatility (network/nodes).
 
 - srpt
-
 - better analysis of the fsync / data reliability impact
-
 - analysis and comparison of Garage at scale
-
 - try to better understand ecosystem (riak cs, minio, ceph, swift) -> some knowledge to get
 
+
+
 ## Notes 
 
 [^ref1]: Yes, we are aware of [Jepsen](https://github.com/jepsen-io/jepsen) existence. This tool is far more complex than our set of scripts, but we know that it is also way more versatile.