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

Add a benchmark to test fetching of many relationships. #49

Draft
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

mattalbr
Copy link
Contributor

This functions as a baseline, to confirm a bug that I believe I spotted which effectively serializes resolution of each relationship.

@codspeed-hq
Copy link

codspeed-hq bot commented Sep 20, 2023

CodSpeed Performance Report

Merging #49 will create unknown performance changes

Comparing mattalbr:benchmark_relationships (c1382fd) with main (9746996)

Summary

🆕 2 new benchmarks
⁉️ 1 dropped benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark main mattalbr:benchmark_relationships Change
🆕 test_load_many_relationships_async[postgresql-postgresql] N/A 286 ms N/A
🆕 test_load_many_relationships[postgresql] N/A 199.3 ms N/A
⁉️ test_hello_world 27.7 µs N/A N/A

@codecov-commenter
Copy link

codecov-commenter commented Sep 20, 2023

Codecov Report

Merging #49 (c1382fd) into main (070ec9a) will increase coverage by 4.75%.
Report is 3 commits behind head on main.
The diff coverage is 98.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #49      +/-   ##
==========================================
+ Coverage   77.37%   82.13%   +4.75%     
==========================================
  Files          10       10              
  Lines         725      907     +182     
  Branches      108      125      +17     
==========================================
+ Hits          561      745     +184     
+ Misses        135      129       -6     
- Partials       29       33       +4     

…sync.

I left a note in the loader's __init__, but to duplicate that here:
Making blocking database calls from within an async function (the resolver) has
catastrophic performance implications. Not only will all resolvers be effectively
serialized, any other coroutines waiting on the event loop (e.g. concurrent requests
in a web server), will be blocked as well, grinding your entire service to a halt.

There's no reason for us to support a foot bazooka, hence the deprecation.
This functions as a baseline, to confirm a bug that I believe I spotted
which effectively serializes resolution of each relationship.
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.

2 participants