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 <>
 patchwork/api/ | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/patchwork/api/ b/patchwork/api/
index 7e04b716af1a..425206443ffe 100644
--- a/patchwork/api/
+++ b/patchwork/api/
@@ -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
 class EventList(ListAPIView):
     """List events."""
+    renderer_classes = (JSONRenderer, )
     serializer_class = EventSerializer
     filter_class = EventFilter
     page_size_query_param = None  # fixed page size

Patchwork mailing list

Reply via email to