Re: [RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server
On 19.08.20 16:19, David Edmondson wrote: > On Wednesday, 2020-08-19 at 15:11:37 +01, Stefan Hajnoczi wrote: > >> On Tue, Aug 18, 2020 at 12:08:36PM +0100, David Edmondson wrote: >>> When using qemu-img to convert an image that is hosted on an HTTP >>> server to some faster local (or pseudo-local) storage, the overall >>> performance can be improved by reading data from the HTTP server in >>> larger blocks and by caching and re-using blocks already read. This >>> set of patches implements both of these, and adds a further patch >>> allowing an offset to be added to all of the HTTP requests. >> >> Hi David, >> Thanks for posting this! Kevin and Max are the maintainers in this area, >> but I wanted to ask an initial question: >> >> Is caching curl-specific or could this be implemented as a block filter >> driver so that it can be stacked on top of other network protocols too? > > This implementation is curl specific, as you probably surmised. I will > look at implementing something similar as a block filter. I think from an implementation standpoint the best would be if we could just use such a generic caching block filter above all curl nodes so we can drop all caching from curl. However, I suppose then we’d at least have the problem of how to put this cache node on top of all curl nodes without breaking compatibility, which may be impossible. OTOH, maybe it would be fine to leave the new cache optional, and just leave the curl driver itself as it is. Which would also mean that wouldn’t need readahead support in the cache driver. But if we do need this full cache directly in the curl driver, is it at least possible to share most of the caching code between it and a (potential future) dedicated cache block driver? Max signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server
On Wednesday, 2020-08-19 at 15:11:37 +01, Stefan Hajnoczi wrote: > On Tue, Aug 18, 2020 at 12:08:36PM +0100, David Edmondson wrote: >> When using qemu-img to convert an image that is hosted on an HTTP >> server to some faster local (or pseudo-local) storage, the overall >> performance can be improved by reading data from the HTTP server in >> larger blocks and by caching and re-using blocks already read. This >> set of patches implements both of these, and adds a further patch >> allowing an offset to be added to all of the HTTP requests. > > Hi David, > Thanks for posting this! Kevin and Max are the maintainers in this area, > but I wanted to ask an initial question: > > Is caching curl-specific or could this be implemented as a block filter > driver so that it can be stacked on top of other network protocols too? This implementation is curl specific, as you probably surmised. I will look at implementing something similar as a block filter. dme. -- Facts don't do what I want them to.
Re: [RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server
On Tue, Aug 18, 2020 at 12:08:36PM +0100, David Edmondson wrote: > When using qemu-img to convert an image that is hosted on an HTTP > server to some faster local (or pseudo-local) storage, the overall > performance can be improved by reading data from the HTTP server in > larger blocks and by caching and re-using blocks already read. This > set of patches implements both of these, and adds a further patch > allowing an offset to be added to all of the HTTP requests. Hi David, Thanks for posting this! Kevin and Max are the maintainers in this area, but I wanted to ask an initial question: Is caching curl-specific or could this be implemented as a block filter driver so that it can be stacked on top of other network protocols too? Thanks, Stefan signature.asc Description: PGP signature
[RFC PATCH 0/9] block/curl: Add caching of data downloaded from the remote server
When using qemu-img to convert an image that is hosted on an HTTP server to some faster local (or pseudo-local) storage, the overall performance can be improved by reading data from the HTTP server in larger blocks and by caching and re-using blocks already read. This set of patches implements both of these, and adds a further patch allowing an offset to be added to all of the HTTP requests. The first patch (block/curl: Add an 'offset' parameter, affecting all range requests) allows the user to add an arbitrary offset to all range requests sent to the HTTP server. This is useful if the image to be read from the HTTP server is embedded in another file (for example an uncompressed tar file). It avoids the need to first download the file containing the source image and extract it (both of which will require writing the image to local storage). It is logically distinct from the rest of the patches and somewhat use-case specific. The remaining patches implement block based retrieval of data from the HTTP server and, optionally, caching of those blocks in memory. The existing HTTP implementation simply reads whatever data is requested by the caller, with the option for a user-specified amount of readahead. This is poor for performance because most IO requests (from QCOW2, for example) are for relatively small amounts of data, typically no more than 64kB. This does not allow the underlying TCP connections to achieve peak throughput. The existing readhead mechanism is also intended to work in conjunction with the HTTP driver's attempt to piggy-back a new IO request on one that is already in flight. This works, but is often defeated because it relies on the existing IO request *completely* satisfying any subsequent request that might piggy-back onto it. This is rarely the case and, particularly when used with "readahead", can result in the same data being downloaded repeatedly. The observed performance will depend greatly on the environment, but when using qemu-img to retrieve a 1GiB QCOW2 image from an HTTPS server, the following was observed: | approach | time (hh:mm:ss) | |+-| | QCOW2 over HTTPS (existing implementation) |00:00:59 | | 256kB blocks, 8 cached blocks |00:00:42 | | 2MB blocks, 100 cached blocks |00:00:34 | By way of comparison, aria2c (a dedicated HTTP download client) can retrieve the same image in 19 seconds. Obviously this is without any QCOW2 layer. David Edmondson (9): block/curl: Add an 'offset' parameter, affecting all range requests block/curl: Remove readahead support block/curl: Tracing block/curl: Perform IO in fixed size chunks block/curl: Allow the blocksize to be specified by the user block/curl: Cache downloaded blocks block/curl: Allow the user to control the number of cache blocks block/curl: Allow 16 sockets/ACB block/curl: Add readahead support block/curl.c | 515 ++ block/io.c| 4 + block/linux-aio.c | 6 + block/trace-events| 18 +- docs/system/device-url-syntax.rst.inc | 15 + qapi/block-core.json | 11 +- 6 files changed, 488 insertions(+), 81 deletions(-) -- 2.27.0