Optimize some management endpoints via the querysets and prefetches#1600
Conversation
…and exports Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
…or catalog index Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
…sets Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
| "queries": { | ||
| "index": 3, | ||
| "list": 9, | ||
| "detail": 9, |
There was a problem hiding this comment.
this mapper defines the max query counts per api endpoint action during a test.
Very simple test at the moment. They could be expanded by creating 10000 Options, Attributes, etc dynamically during test as well..
| 'editors' | ||
| ) | ||
|
|
||
| def get_queryset(self): |
There was a problem hiding this comment.
nearly forgot the Tasks and Views ;)
jochenklar
left a comment
There was a problem hiding this comment.
I am a bit puzzled, why I cannot follow part of your optimizations, maybe we should talks next week.
| 'catalog_sections__section__section_pages__page__page_questions__question__attribute', | ||
| 'catalog_sections__section__section_pages__page__page_questions__question__conditions', | ||
| 'catalog_sections__section__section_pages__page__page_questions__question__optionsets', | ||
| 'catalog_sections__section__section_pages__page__page_questions__question__default_option', |
There was a problem hiding this comment.
I am not convinced prefetching the default_option is needed, since we only use its id in the serializer and do not resolve the instance.
There was a problem hiding this comment.
And what about the QuestionExportSerializer? It uses default_option = serializers.CharField(source='default_option.uri', default=None, read_only=True) so default_option.uri needs to be resolved for exports right?! It would be used by all Export serializers up to the CatalogExport. Would it be worth to add the prefetch field only for export or apply it only for the export actions? Otherwise we can leave it out like you said.
rdmo/rdmo/questions/serializers/export.py
Line 26 in e77e2ca
There was a problem hiding this comment.
So actually, the export of a Catalog via the management interface can make almost 3000(!) queries and debug toolbar crashed my machine a bit.
Is it because of a missing prefetch_elements call in the detail_export?
rdmo/rdmo/questions/viewsets.py
Line 97 in e77e2ca
| 'questionsets', | ||
| 'editors' | ||
| ).select_related('attribute') | ||
| ).select_related('attribute', 'default_option') |
There was a problem hiding this comment.
Same as above, I don't think we use this.
…elated Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
…unctinos and select_related calls Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
|
so, these were the query counts from before the optimizations of the For a catalog 😅 : |
| from .serializers.v1 import ConditionIndexSerializer, ConditionSerializer | ||
|
|
||
|
|
||
| def get_attributes_by_id(): |
There was a problem hiding this comment.
This method is not needed because of .in_bulk(), but if it should go into utils.py or managers.py.
Also this prefetches all (!) attributes, which is overkill.
| ) | ||
|
|
||
| def get_export_renderer_context(self, request): | ||
| def get_export_renderer_context(self, request, attributes_by_id=False): |
There was a problem hiding this comment.
There should be a seperate get_export_serializer_context to for the serializer context.
| def get_parent_data(self, obj): | ||
| if obj.parent is not None: | ||
| return AttributeExportSerializer(obj.parent).data | ||
| parent = self.get_parent_object_from_context(obj) |
There was a problem hiding this comment.
Those to methods are unnecessary complex, part because AI slob and part because the original code with the parent_data was not great. I refactored the whole thing in 2.4.5/fix/optimize-management-querysets+refactor.
There was a problem hiding this comment.
where is this branch 2.4.5/fix/optimize-management-querysets+refactor that you speak of?? 👀 👀
| ) | ||
|
|
||
|
|
||
| def get_attributes_by_id(): |
| raise RuntimeError('uri_path is missing') | ||
| return join_url(uri_prefix or settings.DEFAULT_URI_PREFIX, '/questions/', uri_path) | ||
|
|
||
|
|
There was a problem hiding this comment.
This part (same for the other question models) needs more work. I get that the recursion solves the problem with nested questionsets. However for the full export we need the same attribute_map I implemented for the other models in 2.4.5/fix/optimize-management-querysets+refactor.
Nevertheless, all this code does not belong in models.py. Please create an extra prefetch.py for it and refactor the prefetch_elements methods accordingly. Catalog.prefetch_lookups is not needed anymore. child_questionset_prefetch should be questionset_questionset_prefetch to match the other naming in RDMO.
After this we need to see if we need a special case for default_option since it is only needed for the export and would maybe slow down the answer tree.
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
…ect page Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
…ent-querysets+refactor Refactor queryset optimizations
|
I've made some changes according to your suggestions and included the refactor PR.. |
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
…osen export tests Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
|
Alright, this was quite a ride, but I think/hope/pray that we have a good result now. I did not get why the
@MyPyDavid please check and then merge. |
Signed-off-by: David Wallace <david.wallace@tu-darmstadt.de>
|
ok, thanks @jochenklar! 🙌 |
|
Yes, thanks! |
Description
Related issue: "I think we had an issue from even before the migration to the React interface"
Some managment pages were still loading slowly, one prefetch field
default_optionfor the questions.Models was missing. This may improve some queries.