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

Rework conclusion
All checks were successful
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/pr Build is passing
Details

Browse source
This commit is contained in:
Quentin 2022-06-10 17:49:02 +02:00
parent cf672377f3
commit 0e2689efdb
Signed by: quentin
GPG key ID: E9602264D639FF68
1 changed files with 6 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
content/blog/2022-ipfs/index.md
View file

@ -198,20 +198,19 @@ Even if all requests have not the same cost on the cluster, processing a request
## Conclusion
Running IPFS over a S3 backend does not quite work out of the box in term of performances yet.
We have identified some possible measures for improvement (disabling the DHT server, keeping an in-memory index of the blocks, using the S3 backend only for your data)
that might allow you to still run an IPFS node over Garage.
We have identified that the main problem is linked with the DHT service,
and proposed some improvements (disabling the DHT server, keeping an in-memory index of the blocks, using the S3 backend only for your data).
From a design perspective, it seems however that the numerous small blocks created by IPFS
do not map trivially to efficient S3 requests, and thus could be a limiting factor to any optimization work.
As part of our test journey, we read some posts about performance issues on IPFS (eg. [#6283 - Reduce the impact of the DHT](https://github.com/ipfs/go-ipfs/issues/6283)) that are not
As part of our test journey, we also read some posts about performance issues on IPFS (eg. [#6283](https://github.com/ipfs/go-ipfs/issues/6283)) that are not
linked with the S3 connector. We might be negatively influenced by our failure to connect IPFS with S3,
but we are tempted to think that in any case, IPFS will be ressource intensive for your hardware.
but we are tempted to think that IPFS is intrinsically ressource intensive.
On our side, we will continue our investigations towards more *minimalist* software that tends to limit the
number of requests they send.
On our side, we will continue our investigations towards more *minimalist* software.
This choice makes sense for us as we want to reduce the ecological impact of our services
by deploying optimized software on a limited number of second-hand servers.
by deploying less servers, that use less energy, and that are renewed less frequently.
*Yes we are aware of the existence of Nextcloud, Owncloud, Owncloud Infinite Scale, Seafile, Filestash, Pydio, SOLID, Remote Storage, etc.
We might even try one of them in a future post, so stay tuned!*