please describe what symptom you see, what you would expect to see instead and
how to reproduce it.
I'm the guy using Libtorrent to create a bare-metal provisioning toolkit EZIO.
Nowadays servers have 10G and NVMe SSD mostly.
We are trying to improve the performance for the bare metal deployment for SSD and 10G or above network.
In the past, we usually had SSD PC classroom and 1Gbps link only.
We didn't need to care about the cache or SSD read/write policy at that time because of 1Gbps link. (Even some high perforamcne HDDs can meet 1Gbps speed.)
With Libtorrent 2.0, we don't have any built-in cache right now.
While I change the implementation to pread/pwrite instead of mmap, we can get 450MB/s~600MB/s on XPG SX8200 PRO.
And I also tried to implement cache to speed up the process.
It turned out an unexpected result.
With cache implementation, the process is slowed down to 350~400MB/s (My implementaion is not zero copy cache)
After some analysis, we don't need to transfer the duplicated data to others, we only need to transfer once and that is all.
So droping the cache when the cache is full become a huge performance penalty and block the IO to read ahead.
And another thing, it's not easy to use native torrent handle to add "suggest pieces" for the BT protocol.
That will also cause some cache miss.
This is a fun fact that I don't need cache at all in my program at this stage.
Please provide the following information
libtorrent version (or branch): 2.0.10
platform/architecture: amd64
compiler and compiler version: gcc 14
please describe what symptom you see, what you would expect to see instead and how to reproduce it.
I'm the guy using Libtorrent to create a bare-metal provisioning toolkit EZIO. Nowadays servers have 10G and NVMe SSD mostly. We are trying to improve the performance for the bare metal deployment for SSD and 10G or above network. In the past, we usually had SSD PC classroom and 1Gbps link only. We didn't need to care about the cache or SSD read/write policy at that time because of 1Gbps link. (Even some high perforamcne HDDs can meet 1Gbps speed.)
With Libtorrent 2.0, we don't have any built-in cache right now. While I change the implementation to pread/pwrite instead of mmap, we can get 450MB/s~600MB/s on XPG SX8200 PRO. And I also tried to implement cache to speed up the process. It turned out an unexpected result. With cache implementation, the process is slowed down to 350~400MB/s (My implementaion is not zero copy cache) After some analysis, we don't need to transfer the duplicated data to others, we only need to transfer once and that is all. So droping the cache when the cache is full become a huge performance penalty and block the IO to read ahead. And another thing, it's not easy to use native torrent handle to add "suggest pieces" for the BT protocol. That will also cause some cache miss.
This is a fun fact that I don't need cache at all in my program at this stage.
https://github.com/tjjh89017/ezio/tree/cache
Thanks Arvidn to create this project!