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

Limit the number of search requests running concurrently #4489

Closed
10 tasks
Tracked by #4467
irevoire opened this issue Mar 13, 2024 · 0 comments · Fixed by #4536
Closed
10 tasks
Tracked by #4467

Limit the number of search requests running concurrently #4489

irevoire opened this issue Mar 13, 2024 · 0 comments · Fixed by #4536
Labels
CPU/RAM usage impacts docs This issue involves changes in the Meilisearch's documentation v1.8.0 PRs/issues solved in v1.8.0 released on 2024-05-06
Milestone

Comments

@irevoire
Copy link
Member

irevoire commented Mar 13, 2024

Related product team resources: PRD (internal only)
Related product discussion: https://github.com/orgs/meilisearch/discussions/729
Related spec: WIP

Motivation

The search requests in meilisearch are intensive, which means it’s useless to run multiple searches at the same time.
The most efficient way to treat search requests is to run one search request per core.

But we don't want to refuse search requests straight away when all cores are being used; thus, we're going to keep track of the search requests to process in a queue of fixed-size and then randomly pick the next search request to be processed.

If the queue is full, then Meilisearch will return an error (TBD) with the error code 503 service unavailable and a retry-after header.

Since the size of the queue may vary between use cases, we'll also need to introduce a new global setting for the whole instance, specifying the size of the queue.

See full usage here: https://meilisearch.notion.site/API-usage-of-the-search-limiter-c1edc092f3c746d6899c5ba7bfa9a6a8?pvs=74

Usage

TODO

  • merge changes into main
  • Update the spec

Reminders when modifying the Setting API

  • Ensure the new setting route is at least tested by the test_setting_routes macro
  • Ensure Analytics are fully implemented
  • Ensure the dump serializing is consistent with the /settings route serializing, e.g., enums case can be different (camelCase in route and PascalCase in the dump)

Special cases when adding a setting for an experimental feature

  • ⚠️ API stability: The setting does not appear on the main settings route when the feature has never been enabled (e.g. mark it Unset when returned from the index in this situation. See an example)
  • The setting cannot be set when the feature is disabled, either by the main settings route or the subroute (see validate_settings function)
  • If possible, the setting is reset when the feature is disabled (hard if it requires reindexing)

Impacted teams

@meilisearch/docs-team

@irevoire irevoire added this to the v1.8.0 milestone Mar 13, 2024
@curquiza curquiza added the impacts docs This issue involves changes in the Meilisearch's documentation label Mar 13, 2024
@irevoire irevoire mentioned this issue Mar 14, 2024
3 tasks
@meili-bors meili-bors bot closed this as completed in fa9748c Mar 28, 2024
@meili-bot meili-bot added the v1.8.0 PRs/issues solved in v1.8.0 released on 2024-05-06 label May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CPU/RAM usage impacts docs This issue involves changes in the Meilisearch's documentation v1.8.0 PRs/issues solved in v1.8.0 released on 2024-05-06
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants