refactor: use parallelizable scheduler for explore + entity#93
refactor: use parallelizable scheduler for explore + entity#93aaron-steinfeld merged 1 commit intomainfrom
Conversation
| bind(BaselineDao.class).to(GatewayBaselineDao.class); | ||
| requireBinding(CallCredentials.class); | ||
| requireBinding(GraphQlServiceConfig.class); | ||
| requireBinding(GraphQlRequestContextBuilder.class); |
There was a problem hiding this comment.
Yes. Since I was in there, I switched from the deprecated GraphQlGrpcContextBuilder to GrpcContextBuilder. When I went to switch the binding declaration (which is really just for documentation purposes), I noticed we had accidentally required GraphQlRequestContextBuilder (converts from the raw http to our internal format, which this module doesn't do), instead of GraphQlGrpcContextBuilder (converts from our internal format to a grpc format - which this module does do, and was swapped out)
Codecov Report
@@ Coverage Diff @@
## main #93 +/- ##
============================================
- Coverage 22.19% 22.09% -0.10%
Complexity 66 66
============================================
Files 64 64
Lines 1595 1602 +7
Branches 49 49
============================================
Hits 354 354
- Misses 1234 1241 +7
Partials 7 7
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Description
By default, Rx runs on the current thread. Even though we use async GQL requests, we're not splitting the network calls onto different threads so we're not getting that benefit. Within a batch, the requests currently run in serial. By moving these apis to use our IO scheduler, we now can allow each request to parallelize.
Using a batch of four queries, we see the below behavior (note theads and start/end times):
Before:
After:
Testing
Visually verified query perf and with logging
Checklist: