@@ -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
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 events! 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 <dja@axtens.net> --- patchwork/api/event.py | 3 +++ 1 file changed, 3 insertions(+)