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

Deprioritise ingestion from providers with successive error #2496

Open
masih opened this issue Jan 30, 2024 · 1 comment
Open

Deprioritise ingestion from providers with successive error #2496

masih opened this issue Jan 30, 2024 · 1 comment

Comments

@masih
Copy link
Member

masih commented Jan 30, 2024

There seem to be a cascading error effect, where if a couple of providers repeatedly error during ad traversal they can slow down the ingestion for other providers.

The degree by which ingest is slowed down depends on the number of ingest workers and overall traffic on the indexer.

Indexers should deprioritise ingestion from providers that have errored numerously, with some exponential backoff. This then should allow indexers to make overall progress and come back to erroneous providers which should reduce cascading effects across the system.

@gammazero
Copy link
Collaborator

gammazero commented Feb 9, 2024

On every poll cycle, for each provider that is polled, we record the last poll sequence. In each subsequent poll cycle the providers to poll are sorted according to poll sequence, so those with older poll sequences are preferred. This avoids polling the same providers during each poll period if others should be polled.

Ingestion should only occur repeatedly for errored providers if they are the only ones that should be polled. We could add a backoff timer for providers that have errors across consecutive polls, but polling an errored provider should not affect performance significantly since that does not cause anything that was already synced to be resynced.

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

No branches or pull requests

2 participants