-
Notifications
You must be signed in to change notification settings - Fork 532
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty compression messages #14261
Empty compression messages #14261
Conversation
It would be great to also have end-to-end test, that validates that we are sending substantially fewer bytes over the wire (compared to initial DDS payload) when dealing with large non-random payloads. Including hitting cases of compression, compression + chunking. |
Ok, we need to keep this for back-compat reasons (old loader submit function requires an object passed as opposed to string contents). I'll add a note to enhance some of the end-to-end tests to verify the resulting payload size and add more confidence.. (ADO:3499) |
⯅ @fluid-example/bundle-size-tests: +252 Bytes
Baseline commit: 81b5ef9 |
Reverts #14261 The change surfaced a bug related to the compressed message metadata and fired an incident in our stress tests.
## Description This is resubmitting #14261 which was reverted with #14370 as it was stripping all metadata from the batch. The issue was not caught in testing as the change removed the metadata only for the trailing ops, which broke the stress tests. Adjusted the end-to-end tests to catch similar issues in the future.
…re. (#14587) ## Description ADO:3499 There have been instances in which _we thought_ we were sending the wrong things over the wire (for example messages with duplicated content) like in #14261. However, there is in-flight work related to the message logistics, so it is very important to pin down expectations about the size of the messages we are sending.
Description
We've identified an issue with compression, that the trailing empty ops added to the batch to preserve the batch shape and reserve sequence numbers are not really empty, as the content is still present in thedeserializedContent
property. This leads to compression creating a large payload which does not end up getting chunked.This is not actually an issue. When compression is not supported by the loader, the outbox will send the
deserializedContent
property. When it is, a message will be crafted to only contain contents, metadata, compression and referenceSequenceNumber. So if compression is enabled and supported, the message size will actually be small as thedeserializedContent
value is discarded. This is still a good change, it will make memory consumption smaller when compression is enabled and supported.Example of a compressed batch:
with actual content in the messages which are supposed to be empty:
This made the batch exceed 2.5 MB