Skip to content
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

Merged
merged 8 commits into from
Mar 1, 2023
Merged

Conversation

andre4i
Copy link
Contributor

@andre4i andre4i commented Feb 21, 2023

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 the deserializedContent 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 the deserializedContent 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

@andre4i andre4i requested a review from a team as a code owner February 21, 2023 21:38
@github-actions github-actions bot added area: runtime Runtime related issues base: main PRs targeted against main branch labels Feb 21, 2023
@vladsud
Copy link
Contributor

vladsud commented Feb 21, 2023

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.

@andre4i
Copy link
Contributor Author

andre4i commented Feb 21, 2023

Ok, we need to keep this for back-compat reasons (old loader submit function requires an object passed as opposed to string contents). We could work around it, but it would add a performance hit as we'd be doing JSON.parse twice for the same message when compression happens this is fine to do for this scenario.

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)

@andre4i andre4i closed this Feb 21, 2023
@andre4i andre4i reopened this Feb 21, 2023
@msfluid-bot
Copy link
Collaborator

@fluid-example/bundle-size-tests: +252 Bytes
Metric NameBaseline SizeCompare SizeSize Diff
aqueduct.js 433.72 KB 433.84 KB +126 Bytes
connectionState.js 680 Bytes 680 Bytes No change
containerRuntime.js 228.83 KB 228.95 KB +126 Bytes
loader.js 152.93 KB 152.93 KB No change
map.js 43.78 KB 43.78 KB No change
matrix.js 135.95 KB 135.95 KB No change
odspDriver.js 91.79 KB 91.79 KB No change
odspPrefetchSnapshot.js 43.51 KB 43.51 KB No change
sharedString.js 156.5 KB 156.5 KB No change
Total Size 1.36 MB 1.36 MB +252 Bytes

Baseline commit: 81b5ef9

Generated by 🚫 dangerJS against 34f4181

@andre4i andre4i merged commit 30a2205 into microsoft:main Mar 1, 2023
andre4i added a commit that referenced this pull request Mar 1, 2023
andre4i added a commit that referenced this pull request Mar 1, 2023
Reverts #14261

The change surfaced a bug related to the compressed message metadata and
fired an incident in our stress tests.
andre4i added a commit that referenced this pull request Mar 2, 2023
## 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.
andre4i added a commit that referenced this pull request Mar 16, 2023
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: runtime Runtime related issues base: main PRs targeted against main branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants