Erratum: Tesseract/POSIX uses BadgerDB, not MariaDB, h/t alcutter@
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
@@ -621,12 +621,13 @@ to the task of serving the current write-load (which is about 250/s).
|
||||
|
||||
* ***S3***: When using the S3 backend, TesseraCT became quite unhappy above 800/s while Sunlight
|
||||
went all the way up to 4'200/s and sent significantly less requests to MinIO (about 4x less),
|
||||
while showing good telemetry on the use of S3 backends.
|
||||
while showing good telemetry on the use of S3 backends. In this mode, TesseraCT uses MySQL (in
|
||||
my case, MariaDB) which was not on the ZFS pool, but on the boot-disk.
|
||||
|
||||
* ***POSIX***: When using normal filesystem, Sunlight seems to peak at 4'800/s while TesseraCT
|
||||
went all the way to 12'000/s. When doing so, Disk IO was quite similar between the two
|
||||
solutions, taking into account that TesseraCT runs MariaDB (which my setup did not use ZFS
|
||||
for), while Sunlight uses sqlite3 on the ZFS pool.
|
||||
solutions, taking into account that TesseraCT runs BadgerDB, while Sunlight uses sqlite3,
|
||||
both are using their respective ZFS pool.
|
||||
|
||||
***Notable***: Sunlight POSIX and S3 performance is roughly identical (both handle about
|
||||
5'000/sec), while TesseraCT POSIX performance (12'000/s) is significantly better than its S3
|
||||
|
Reference in New Issue
Block a user