Compare commits
1 Commits
main
...
doc/benchm
Author | SHA1 | Date |
---|---|---|
Quentin Dufour | 1be1715522 | 2 years ago |
@ -0,0 +1,8 @@ |
||||
+++ |
||||
title = "Benchmarks" |
||||
weight = 60 |
||||
sort_by = "weight" |
||||
template = "documentation.html" |
||||
+++ |
||||
|
||||
Hello |
@ -0,0 +1,17 @@ |
||||
+++ |
||||
title = "Abstraction cost" |
||||
weight = 30 |
||||
+++ |
||||
|
||||
We take as our baseline the raw disk sequential write performance. |
||||
We then compare Garage's performances to it, the difference represents what we call our "abstraction cost". |
||||
|
||||
fsync, chunking, compression, pipelining, synchronization |
||||
|
||||
# raw perf VS garage |
||||
|
||||
# garage tmpfs VS garage std |
||||
|
||||
# garage various multipart sizes |
||||
|
||||
# garage 0.7.2.1 VS upstream |
@ -0,0 +1,18 @@ |
||||
+++ |
||||
title = "Failure & recovery" |
||||
weight = 50 |
||||
+++ |
||||
|
||||
# Failure impact |
||||
|
||||
Failures will lead to timeouts, which in turn could |
||||
lead to failed requests (this is a bug if failure enters in Garage tolerance) |
||||
and to increased latency as some retries might be performed. |
||||
|
||||
How we proceed: we pause (`kill -STOP xxx`) one Garage process. |
||||
The idea is we don't want to close the TCP connection that would signal too easily |
||||
that a crash occured. Instead, we want to simulate a network error |
||||
or an overloaded process, ie. a 'non-collaborating' crash. |
||||
|
||||
|
||||
# Recovery impact |
@ -0,0 +1,14 @@ |
||||
+++ |
||||
title = "Industry tools" |
||||
weight = 60 |
||||
+++ |
||||
|
||||
|
||||
# minio warp |
||||
|
||||
# intel-cloud cosbench |
||||
|
||||
# (non retenu) |
||||
|
||||
- wasabi s3-benchmark |
||||
- https://github.com/dvassallo/s3-benchmark |
@ -0,0 +1,10 @@ |
||||
+++ |
||||
title = "Liveness" |
||||
weight = 40 |
||||
+++ |
||||
|
||||
freedom from starvation, backpressure, etc. |
||||
|
||||
# Responsiveness under read/write load |
||||
|
||||
|
@ -0,0 +1,14 @@ |
||||
+++ |
||||
title = "Network sensitiveness" |
||||
weight = 10 |
||||
+++ |
||||
|
||||
impact of node count and their latency |
||||
|
||||
# Latency amplification |
||||
|
||||
# Cluster size impact |
||||
|
||||
# Time-To-First-Byte (TTFB) |
||||
|
||||
with various object size |
@ -0,0 +1,16 @@ |
||||
+++ |
||||
title = "Pushing limits" |
||||
weight = 60 |
||||
+++ |
||||
|
||||
# Many objects |
||||
|
||||
# Huge objects |
||||
|
||||
# Many nodes (horizontal scalability) |
||||
|
||||
|
||||
|
||||
# Large nodes (vertical scalability) |
||||
|
||||
|
@ -0,0 +1,8 @@ |
||||
+++ |
||||
title = "Real world" |
||||
weight = 80 |
||||
+++ |
||||
|
||||
# Nextcloud |
||||
|
||||
# Peertube |
Loading…
Reference in new issue