[adding libguestfs list, for nbdkit reference below]
On 10/4/18 8:39 AM, Stefan Fröberg wrote:> Hello.
> Is it possible to improve NBD throughtput with LZO compression ?
As in, have a way for the client and server to negotiate that both
understand an LZO extension, at which point the client can request a
read or write with a flag set to mark that the data is LZO-compressed,
for less network traffic but higher CPU usage between the client and server?
The idea might have merit, you're certainly welcome to propose it as an
extension (we can help with word-smithing the extension into the NBD
specification and ideas of the best way to negotiate the feature); it is
also helpful if you also plan on showing a reference implementation of
both a server and client implementing the extension.
Would it always have to be LZO compression, or would it be smarter to
have the negotiation phase pass a list of names of compression
algorithms, where clients and servers can both advertise their list of
algorithms they support, and then settle on one that is common to both
sides? Is it better to request that ALL read/write transactions
automatically be compressed by the negotiated algorithm, or only the
specific transactions where the client requests compression (after all,
the overhead of compressing a small transaction might be worse than just
sending the data directly; while the benefits of increased CPU times for
compression/decompression are more likely to matter for large
transactions where the transmission time becomes the bottleneck).
On a different track, you may want to try some experiments with LZO
compression by using nbdkit. Assuming that the real bottleneck that you
are trying to speed up is TCP/IP traffic, while local NBD connections
over a Unix socket are much faster, you could replace:
client => uncompressed over TCP/IP => server
with
client => uncompressed over Unix => nbdkit with custom plugin =>
compressed over TCP/IP => custom wrapper => server
where you write a wrapper on the server side to perform the LZO
compression (nbdkit does not yet provide a plugin library for easy
writing of a client, but maybe it should), then a plugin on the client
side that can interpret your LZO-compressed stream on the client side.
nbdkit already comes with a plugin that can read from .xz files
(slightly different from compressing individual transactions). But the
point remains that if what you are trying to design is an alternative
network stream with compressed data while still having a traditional NBD
interface once the data is local, then using nbdkit or other
intermediaries as boundary points can prove useful.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
