apache
TS_USE_MMAP: mmap+memcopy instead pread+pwrite
Allows for only-in-memory caching for usecases where such behavior is needed (i.e. Live Video caching). It maps storage directly into user space memory, so reads and writes are being done by a memcpy (without calls to io).
apt install libaio-dev autoreconf -if ./configure --enable-mmap --enable-experimental-linux-native-aio ./configure --enable-mmap
Do you have a benchmark comparing the performance of mmap vs pread?
New features would go into the master branch and we most likely wouldn't backport this change into 9.x at this point in time because we are focusing on releasing ATS 10.
If this feature gets added to master / ATS 10. You could cherry pick the change to your branch of 9.x.
is there a reason why this cannot be a configuration parameter in records.yaml and has to be a compile time option?
@bryancall In a Sapphire Rapids system with 100Gbps NIC we observed 10x lower mean latency (2.7ms vs 28ms), also maximum obtainable transfer rate was higher by 22% (9.4GBps bs 7.7GBps). Test was done on Ubuntu 22.04 using vegeta, live video 1080p simulation (1MB objects), TLS, 30% cold cache, 70% cached, total volume of 14GB of cached objects.
The main use cases are the users who are targeting lower-volume data with very low desired latency (like live video).
@SolidWallOfCode Hello Alan, would you like us to provide additional information so that the PR can be approved? Best Regards Maciej
We developed it for 9.2.x, but we can also make it work for the master branch. Can it be incorporated into 9.2?
@moleksy Our development flow is a). merge in to the master branch first, and b). backport commits to the latest branch if needed
Please open a PR against the master branch. (or change the target branch of this PR) You might need to adjust your autotools config into CMake because we're in the middle of building tool migration.
In a Sapphire Rapids system with 100Gbps NIC we observed 10x lower mean latency (2.7ms vs 28ms), also maximum obtainable transfer rate was higher by 22% (9.4GBps bs 7.7GBps).
We also need more benchmark with this, but the number you talked is pretty interesting.
