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

RUMM-3151 feat: reduce number of view updates by looking ahead duplicate events… #1328

Merged
merged 20 commits into from
Jun 30, 2023

Conversation

ganeshnj
Copy link
Contributor

@ganeshnj ganeshnj commented Jun 23, 2023

What and why?

There are several view updates happens which are not needed. These view updates are reduced by the backend anyway, but we could reduce the number of view updates by filtering them out from the payload.

How?

While saving RUMViewEvent to disk, we save the metadata along with it. This allows us to access key information without decoding the whole event. While preparing the request body, we filter out the events which are duplicate and will be sent in the same batch.

Review checklist

  • Feature or bugfix MUST have appropriate tests (unit, integration)
  • Make sure each commit and the PR mention the Issue number or JIRA reference
  • Add CHANGELOG entry for user facing changes

Custom CI job configuration (optional)

  • Run unit tests
  • Run integration tests
  • Run smoke tests

@ganeshnj ganeshnj force-pushed the ganeshnj/feat/reduce-view-updates branch 2 times, most recently from 32f1649 to 6c541e5 Compare June 23, 2023 14:20
@datadog-datadog-prod-us1
Copy link

datadog-datadog-prod-us1 bot commented Jun 23, 2023

Datadog Report

Branch report: ganeshnj/feat/reduce-view-updates
Commit report: 00a1e06

dd-sdk-ios: 0 Failed, 0 New Flaky, 2191 Passed, 0 Skipped, 15m 9.22s Wall Time

@ganeshnj ganeshnj marked this pull request as ready for review June 26, 2023 11:33
@ganeshnj ganeshnj requested a review from a team as a code owner June 26, 2023 11:33
Copy link
Member

@maciejburda maciejburda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a first pass. Looking good. Some minor suggestions 🙌

Sources/Datadog/RUM/RUMV2Configuration.swift Outdated Show resolved Hide resolved
ganeshnj added 5 commits June 26, 2023 14:08
…m payload

### What and why?

There are several view updates happens which are not needed. These view updates are reduced by the backend anyway, but
we could reduce the number of view updates by filtering them out from the payload.

### How?

While saving RUMViewEvent to disk, we save the metadata along with it. This allows us to access key information without
decoding the whole event. While preparing the request body, we filter out the events which are duplicate and will be
sent in the same batch.
@ganeshnj ganeshnj force-pushed the ganeshnj/feat/reduce-view-updates branch from 4b1a196 to 84beb87 Compare June 26, 2023 12:08
Copy link
Member

@maxep maxep left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good, nice work!

I've left a blocking change about separating RUM specifics from DatadogInternal to facilitate merging with v2 👍

Sources/Datadog/DatadogInternal/Upload/Event.swift Outdated Show resolved Hide resolved
Sources/Datadog/RUM/RUMV2Configuration.swift Outdated Show resolved Hide resolved
Copy link
Member

@ncreated ncreated left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks definitely good 👌👍, but I left few points with one blocker.

Copy link
Member

@maxep maxep left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great !!

Copy link
Member

@ncreated ncreated left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @ganeshnj 👌. Before we can go with merge:

  • Please update the PR and branch name to our convention (notably, we must reference to RUMM-3151 for future visibility of "why?" we decided on that change)
  • What about the second part from Definition Of Done in RUMM-3151? Without dropping the old "view update throttling" logic we are not solving the "1ns views problem" stated in the spec. With this PR we drop unnecessary updates, but we still don't let the valid ones in. It is still an increment what we have here, so we can tackle this part separately (it will imply quite impactful change in tests). Happy to chat about this to give you more context 🙌.

Comment on lines +14 to +18
/// Metadata associated with the event.
/// Metadata is optional and may be `nil` but of very small size.
/// This allows us to skip resource intensive operations in case such
/// as filtering of the events.
public let metadata: Data?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit/ Because we pass metadata in write<E: Encodable, M: Encodable>(event: E, metadata: M) the feature doesn't know the actual detail of metadata: Data encoding. We should clearly state in this comment that metadata: Data? is JSON encoded. Actually, the same comment should be applied to data: Data field.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I disagree with it, the JSON part comes from the FileWriter

Here Event is just an intermediately representation, which starts from FileWriter because we writing the metadata in JSON. (this can be changed to anything per needs).

https://github.com/DataDog/dd-sdk-ios/blob/develop/Sources/Datadog/DatadogCore/Storage/Writing/FileWriter.swift#L50

Then, it is feature specific filters, in this case RUMViewEventsFilter

internal struct RUMViewEventsFilter {
    let decoder: JSONDecoder

    init(decoder: JSONDecoder = JSONDecoder()) {
        self.decoder = decoder
    }

which knows metadata is JSON (FileWriter is using JSONEncoder). As we discussed, how Event is decoded is totally transparent to the Core logic of the SDK.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, responsibilities are not properly assigned: Core owns the encoding while Features are responsible of decoding. JSON encoding/decoding is only a convention between the core and Features, so I think it should be mentioned in comments.

Ultimately, I think we should transfer responsibility of encoding to the Features, so they are free to use the serialisation of their choices (JSON, TLV, protobuf, ...). Not a change request of this PR but something to consider in the future.

@ganeshnj
Copy link
Contributor Author

ganeshnj commented Jun 29, 2023

Nice work @ganeshnj 👌. Before we can go with merge:

  • Please update the PR and branch name to our convention (notably, we must reference to RUMM-3151 for future visibility of "why?" we decided on that change)
  • What about the second part from Definition Of Done in RUMM-3151? Without dropping the old "view update throttling" logic we are not solving the "1ns views problem" stated in the spec. With this PR we drop unnecessary updates, but we still don't let the valid ones in. It is still an increment what we have here, so we can tackle this part separately (it will imply quite impactful change in tests). Happy to chat about this to give you more context 🙌.

I realized the branch name as soon as I put the PR for review, the problem with branch name, I have to re-do the PR.

For the 1ns issue - I want to tackle in a separate PR and not convolute this PR (keep it filtering specific). Let's chat about 1ns thing, will ping you on side.

@ganeshnj ganeshnj changed the title feat: reduce number of view updates by looking ahead duplicate events… RUMM-3151 feat: reduce number of view updates by looking ahead duplicate events… Jun 29, 2023
Copy link
Member

@ncreated ncreated left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🏆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants