@breizh de même
"asynchronous disk I/O" by the dev of libtorrent (the one used by qBT, not the rTorrent one) in 2012: https://blog.libtorrent.org/2012/10/asynchronous-disk-io/
This doesn't matter for light usage, but on a big dedicated server and hundreds of torrents, it's another story
threads seem to be the key... looks like rTorrent has a long way to go
- https://github.com/rakshasa/rtorrent/issues/1009
- https://github.com/rakshasa/rtorrent/issues/1010
- https://github.com/rakshasa/rtorrent/issues/1006
- https://github.com/rakshasa/rtorrent/issues/1011
I'll see how qBT does over the span of a couple of days, but for now it's much better than everything I used before in terms of performance
I only bumped the async i/o threads to 32 (from 10) because I have 32 cores. I uses more RAM (~8 GB) but I have 96 so it's fine...
ok so I moved all my torrents from rTorrent to qBT on my actual seedbox, it's night and day
@aspie4K indefinite (I mean until someone decides to change the pricing model I guess but that's not planned afaik )
@aspie4K this is in the free tier:
- 75 GB of storage
- 75 GB of cold storage (GLACIER)
- 75 GB egress
- ∞ egress to scaleway services in the same region
- ∞ ingress
- ∞ requests
Visualize Go process metrics in real-time https://nakabonne.dev/posts/gosivy/
@aspie4K indeed, a CDN can't hurt
@aspie4K You can't use two object storage providers at the same time on Mastodon, FYI
@aspie4K (disclaimer: I work at scaleway on object storage)
tired of computers