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

PERF-3888 Add low-priority background operation to sinusoidal workload #841

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

pvselvan
Copy link
Collaborator

Active: [1]
NopInPhasesUpTo: *NumPhases
PhaseConfig:
# Add a large set of expired documents at start to make sure TLL monitor doesn't catch up in future phases.
Copy link
Member

Choose a reason for hiding this comment

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

Did we confirm in the FTDC data that we were indeed always behind on TTL deletes?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Based on the FTDC data, the TTL monitor is deleting fewer documents than it was deleting after the load phase, but @haleyConnelly is there another metric I should be using besides deletedDocuments to measure this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, in general there should be a queueLength of non-zero to show low priority operations are at least queueing. Compared to the load phase, aren't there more threads the TTL is competing with in phase 2?

Copy link
Contributor

@haleyConnelly haleyConnelly left a comment

Choose a reason for hiding this comment

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

Holding off until there is information about the FTDC data.

If the TTL deletes are being deprioritized, we should see a "concurrentTransactions write lowPriority queueLength" of greater than 0

@pvselvan
Copy link
Collaborator Author

I'm not observing "queueLength" in the FTDC data, but I am seeing a lot of other "concurrentTransactions write lowPriority" metrics. Is queueLength nested in another metric?

OperationMetricsName: ReadDocs
ThrowOnFailure: false

- TemplateName: UpdatesActorWithSleepTemplate
Copy link
Collaborator Author

@pvselvan pvselvan Mar 29, 2023

Choose a reason for hiding this comment

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

Updating indexed documents definitely adds more stress to the system. Though the "eviction worker thread active" doesn't exceed 4, it is consistently at 4, which would imply that they're doing a lot of work? Let me know if you have other suggestions.

With this phase, we are able to see pretty decent improvements in average throughput and latency.

Copy link
Member

Choose a reason for hiding this comment

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

How big were the throughput/latency improvements? And how about the percentile latencies?

OperationMetricsName: ReadDocs
ThrowOnFailure: false

- TemplateName: UpdatesActorWithSleepTemplate
Copy link
Member

Choose a reason for hiding this comment

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

How big were the throughput/latency improvements? And how about the percentile latencies?

Copy link
Contributor

@haleyConnelly haleyConnelly left a comment

Choose a reason for hiding this comment

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

Are we not seeing queueLength at all, or is it zero (and masked in t2 unless you select the option to "show all-zero charts")

Active: [1]
NopInPhasesUpTo: *NumPhases
PhaseConfig:
# Add a large set of expired documents at start to make sure TLL monitor doesn't catch up in future phases.
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, in general there should be a queueLength of non-zero to show low priority operations are at least queueing. Compared to the load phase, aren't there more threads the TTL is competing with in phase 2?

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.

None yet

3 participants