Frame optimizations

[stebet]

Proposed Changes

• Buffers outbound frames using a Channel, and create a background task that consumes from that channel and writes to the socket. This makes for more efficient buffering of outbound frames as well as removes that write-lock from the SocketFrameHandler since there is only ever one writer accessing the socket.
• As a result, we also get rid of a temporary list allocation when writing frame sets, and we can simplify the command->frame splitting code as well as simplify the socket writers.

Types of Changes

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)

Checklist

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

[stebet]

Memory usage before:

Memory usage after:

CPU usage before:

CPU usage after:

[stebet]

One failed test... taking a look.

[stebet]

Ahhh, the test is broken :) It's failing to copy the buffers of the received messages, and is therefore breaking our new rule in 6.0 to make sure to copy the contents of the message body in the event handlers.

[michaelklishin]

@stebet please rebase this on top of master. Thank you.

[stebet]

Arrghh.... think I royally messed up this rebase...

[stebet]

Ok, think I managed to fix it :)

[michaelklishin]

@stebet should I backport this?

[stebet]

Should be safe. @bording ?

[bording]

I think the rebase was still not right, because it looks like this is PR changed the site submodule, which I wouldn't expect this PR to touch.

Should be safe. @bording ?

Yeah I think this would be okay to bring over to 6.1.0. There's no behavior or public API changes.

[michaelklishin]

Backported to 6.x.

[stebet]

The submodule keeps giving me a headache, and sneaking in there. Is there a way to ignore it automatically?

[bording]

@michaelklishin I think you'll need to fix the submodule on master and 6.x

[michaelklishin]

I wouldn't do it even if there was. Don't worry about it, docs can always be regenerated and we are not introducing any meaningful enough API changes most of the time. When we do for 7.0, doc updates will have to be a part of the release, including rabbitmq-tutorials and website updates.

…

________________________________ From: Stefán Jökull Sigurðarson <notifications@github.com> Sent: Monday, May 25, 2020 8:00 PM To: rabbitmq/rabbitmq-dotnet-client <rabbitmq-dotnet-client@noreply.github.com> Cc: Michael Klishin (Pivotal) <mklishin@pivotal.io>; State change <state_change@noreply.github.com> Subject: Re: [rabbitmq/rabbitmq-dotnet-client] Frame optimizations (#844) The submodule keeps giving me a headache, and sneaking in there. Is there a way to ignore it automatically? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frabbitmq%2Frabbitmq-dotnet-client%2Fpull%2F844%23issuecomment-633653270&data=02%7C01%7Cklishinm%40vmware.com%7C97cc699f716e414f1faa08d800cd304a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260228568529724&sdata=rQxgAD%2F1npEpWdaUkuc4NApkflluSyIVfztVGQuVleU%3D&reserved=0>, or unsubscribe<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAAAIQXPMRRMB36VG6FID2LRTKP4LANCNFSM4NHJVMVQ&data=02%7C01%7Cklishinm%40vmware.com%7C97cc699f716e414f1faa08d800cd304a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260228568529724&sdata=1dAK2riPey0jJVZ0oLu%2B4u%2BmOpLnGotTDmssHy%2FTzKw%3D&reserved=0>.