fix!: lipome compute task optim#613
Conversation
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
feb878f to
84e0b0b
Compare
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
2be79ad to
de5250f
Compare
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon |
| print("response\n", response.json()[0]) | ||
| print("expected\n", expected_response[0]) | ||
| print("----\n") | ||
| print(response.json()[0]["key"]) | ||
| print("----\n") |
There was a problem hiding this comment.
Is it meant to stay in the test suite?
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon |
077a79f to
13ef406
Compare
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon |
|
/e2e --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue, substra-tests=fix/compute-task-performance-issue |
|
Error: Invalid ref |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
End to end tests: ❌ FAILURE It'll stay between us, no one needs to know. |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
End to end tests: ✔️ SUCCESS “Shaken, not stirred.” ― James Bond, Goldfinger |
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
Signed-off-by: SdgJlbl <sarah.diot-girard@owkin.com>
7dddb68 to
5bea4da
Compare
| models.When(start_date__isnull=True, then=0), | ||
| default=Extract(Coalesce("end_date", Now()) - models.F("start_date"), "epoch"), | ||
| return ( | ||
| ComputeTask.objects.filter(channel=get_channel_name(self.request)) |
There was a problem hiding this comment.
Is there a difference between using ComputeTask.objects and super().get_queryset()?
There was a problem hiding this comment.
I don't think so, I feel like it's slightly more explicit not to use super() given that there is some multiple inheritance with mixins here, but maybe I'm missing some under-the-hood optimization...
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
End to end tests: ❌ FAILURE “Boy, that escalated quickly.” ― Ron Burgundy, Anchorman: The Legend of Ron Burgundy |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
/e2e --tests sdk,frontend,substrafl --benchmarks mnist,camelyon --refs substra=fix/compute-task-performance-issue,substra-tests=fix/compute-task-performance-issue |
|
End to end tests: ✔️ SUCCESS “It’s alive! It’s alive!” ― Henry Frankenstein, Frankenstein |
Companion PR
Breaking changes
/compute_plans/<pkey>/tasksnow returns the ComputeTask without their associated inputs and outputs./tasksnow returns the ComputeTask without their associated inputs and outputs./tasks/<pkey>still returns the full view of the ComputeTask (including inputs and outputs).Description
Fixes slow page display (list view of compute tasks linked to a compute plan).
Two issues have been fixed:
prefetch_relatedstatementsThe serializer for the list view does not contain any information about inputs and outputs, since these information are not used currently and make a lot of queries to get nested objects.
The serializer for the detail view is the same as it was before (optimised queries though).
How has this been tested?
This has been tested manually for the frontend part, comparing the version actually in production with a local cluster built on my branch. Pages that were checked:
For the backend, I have added non-regression tests that check that the number of queries is in O(1). The so-called n+1 queries issue is caused by some missing
prefetch_relatedstatement that causes the number of queries to be linear in the number of items. In our case, because of nested items, we actually have a complexity that is higher than linear without theprefetch_related.Impact
TODO
Checklist