[Libguestfs] More parallelism in VDDK driver (was: Re: CFME-5.11.7.3 Perf. Tests)

[Richard W.M. Jones]

On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote:
> Can we use something like the file plugin? thread pool of workers,
> each keeping open vddk handle, and serving requests in parallel from
> the same nbd socket?

Yes, but this isn't implemented in the plugins, it's implemented in
the server.  The server always uses a thread pool, but plugins can opt
for more or less concurrency by adjusting the thread model:

  http://libguestfs.org/nbdkit-plugin.3.html#Threads

The file plugin uses PARALLEL:

  $ nbdkit file --dump-plugin | grep thread
  max_thread_model=parallel
  thread_model=parallel

The VDDK plugin currently uses SERIALIZE_ALL_REQUESTS:

  $ nbdkit vddk --dump-plugin | grep thread
  max_thread_model=serialize_all_requests
  thread_model=serialize_all_requests

The proposal is to use SERIALIZE_REQUESTS, with an extra mutex added
by the plugin around VixDiskLib_Open and _Close calls.  PARALLEL is
not possible.

> This is kind of ugly but simple, and it works great for the file
> plugin - we get better
> performance than qemu-nbd.
>
> But since we get low throughput even when we have 10 concurrent
> handles for 10 different disks, I'm sure this will help, and the
> issue may be deeper in vmware. Maybe they intentionally throttle the
> clients?

The whole server side seems very heavyweight, judging by how long it
takes to answer single requests.  It might just be poor implementation
rather than throttling though.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW