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

feat: improve performance (esp. n+1) by batching requests #107

Merged
merged 1 commit into from
Nov 2, 2024

Conversation

LucianBuzzo
Copy link
Contributor

Prisma will perform query optimizations at the engine level if multiple similar queries are sent inside the same tick, by automatically batching them together into a single larger query. This feature dramatically improves performance for graphQL servers, avoiding the "n+1" problem. By default, Prisma will batch requests by the transaction ID if it is present, but this behaviour prevents automatic batching from working when using Yates, since all queries are executed inside an interactive transaction. To get around this we by monkey patching the batching function to use the Yates ID as the batch ID. To get the batching to work we also need to ensure that all the requests we might want to batch together are generated inside the same tick. This means that all the requests per-tick that have the same role and context values will be batched together, allowing the in-built prisma batch optimizations to work for us. This is why we use process.nextTick and the tickActive flag to ensure we only tick once at a time. See:

Copy link
Contributor

github-actions bot commented Nov 1, 2024

Published beta package version: 3.5.2-beta.dangerous.69a1a81

Prisma will perform query optimizations at the engine level if multiple
similar queries are sent inside the same tick, by automatically batching
them together into a single larger query. This feature dramatically
improves performance for graphQL servers, avoiding the "n+1" problem.
By default, Prisma will batch requests by the transaction ID if it is present,
but this behaviour prevents automatic batching from working when using Yates, since all queries are executed inside an interactive transaction.
To get around this we by monkey patching the batching function to use the Yates ID as the batch ID.
To get the batching to work we also need to ensure that all the requests we might want to batch together are generated inside the same tick.
This means that all the requests per-tick that have the same role and context values will be batched together,
allowing the in-built prisma batch optimizations to work for us.
This is why we use process.nextTick and the tickActive flag to ensure we only tick once at a time.
See:
- https://github.com/prisma/prisma/blob/5.21.1/packages/client/src/runtime/RequestHandler.ts#L122
- https://www.prisma.io/docs/orm/prisma-client/queries/query-optimization-performance
Copy link

sonarcloud bot commented Nov 1, 2024

Quality Gate Failed Quality Gate failed

Failed conditions
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

@sebmellen
Copy link
Member

Fantastic work

@sebmellen sebmellen merged commit 2de8f97 into master Nov 2, 2024
6 of 7 checks passed
@sebmellen sebmellen deleted the lucianbuzzo/query-batching branch November 2, 2024 03:28
@Pehesi97
Copy link

Pehesi97 commented Nov 2, 2024

Great work indeed

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.

3 participants