Something is very, very slow in the d-r-f browsable API events renderer.
In my MySQL test (~33k patches), the CPU time to render the events list
is ~11s, and the time taken by SQL queries is only ~3s. If the JSON
renderer is used, that drops to 0.2s for the entire page (because less
CPU is used, and - for some as yet unknown reason - a *very* expensive
db query is dropped.)
In my PostgreSQL test (~100k patches), the results are even more stark:
30s of CPU time and 0.2s of DB time goes to 0.25s for the entire page.
Something is seriously, seriously wrong with whatever d-r-f is doing.
So, simply render the event list as bare JSON for now.
There are a few followups we should do, but this worth doing now -
no-one should be able to DoS a patchwork server by just enumerating the
In particular, we should find out:
- why postgres and mysql behaviour is so different.
- what on earth d-r-f is doing that makes rendering the pretty-printed
version so incredibly slow.
Signed-off-by: Daniel Axtens <d...@axtens.net>
patchwork/api/event.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/patchwork/api/event.py b/patchwork/api/event.py
index 7e04b716af1a..425206443ffe 100644
@@ -22,6 +22,7 @@ from collections import OrderedDict
from rest_framework.generics import ListAPIView
from rest_framework.serializers import ModelSerializer
from rest_framework.serializers import SerializerMethodField
+from rest_framework.renderers import JSONRenderer
from patchwork.api.embedded import CheckSerializer
from patchwork.api.embedded import CoverLetterSerializer
@@ -85,9 +86,11 @@ class EventSerializer(ModelSerializer):
read_only_fields = fields
+ renderer_classes = (JSONRenderer, )
serializer_class = EventSerializer
filter_class = EventFilter
page_size_query_param = None # fixed page size
Patchwork mailing list