Benchmarking and Performance Improvements

[carltongibson]

Over the years we've had a number of suggestions (collected below) for improving DRF performance. These have often stalled for lack of a suitable benchmarking measure.

Progress on these issues requires:

• A benchmarking project that we can keep up to date and run repeatedly against proposed changes (and the base branch for comparison).

With that in place we could sensibly assess changes, and either accept or reject them, rather than leaving them to rot indefinitely in the issue tracker.

Design Note: Performance isn't a primary goal of Django REST Framework. Rather we're into clarity and ease-of-use. (Other speed-ups, e.g. caching at another level, are often the way to go anyway.) Clean changes that are performance wins are still wins: they're worth having.

Related Tickets:

List of tickets suggesting improvements. Not necessarily complete (— Do add relevant issues!). Blocked by lack of benchmarking. Worth revisiting once we have a solution in place.

• Document explicit speedup approaches. #1994 Document explicit speedup approaches.
• Test template rendering performance for HTMLRenderer. #2093 Test template rendering performance for HTMLRenderer.
• Cache/pickle performance for Serializer data (many=True) #2454 Cache/pickle performance for Serializer data (many=True)
• ModelSerializer caching. #2504 ModelSerializer caching.
• Calling reverse is very expensive #3007 Calling reverse is very expensive (Fixed in Django)
• Serializer - one level copy instead of deepcopy #4587 Serializer - one level copy instead of deepcopy. (Does it handle nesting?)

[xordoquy]

I have a couple handy that I need to benchmark as well.

[carltongibson]

@xordoquy Please add them to the list! 🙂

I'm closing the related tickets as blocked until we can solve this benchmarking issue: then we'll (be able to) re-open/re-assess, and make a final decision.

[JockeTF]

I nominate #3007.

[carltongibson]

@JockeTF Yes. Good call. Thanks. That ticket also links to @thedrow's https://github.com/thedrow/drf-benchmarks project, which I had forgotten about. Maybe there's ideas was can pick up from there.

[tomchristie]

I'd like to close this off. Perfectly happy to see benchmarking tools, but I don't think there's any obvious need to address this as part of the core project. Number-of-query issues are already handled in the issue tracker, and in any case are now all pretty matured. Serializers have a bit of overhead for very large unpaginated list responses, but the large number of API hooks prevents us being able to make much in the way of changes there. I'd expect the only substantial improvements on that side would need to be an alternative fresh serializer implementation. Anyways short version - I don't think we need an actively open ticket for creating a benchmark right now.

[arski]

Hi there, are you sure about this? we have overridden the default get_fields with the following and on some requests which serialize 500 objects with an average of 2-3 nested in each we see an improvement from 60s per response to 20s... There can be arguments made whether such an API endpoint is well designed, but the bottom line is that the caching most definitely improves our APIs performance across the site, even for small endpoints...

class CachedModelSerializer:
    _cached_get_fields_response = {}

    def get_fields(self):
        if self.__class__ not in self.__class__._cached_get_fields_response:
            self.__class__._cached_get_fields_response[self.__class__] = super().get_fields()

        return copy.deepcopy(self.__class__._cached_get_fields_response[self.__class__])

PS I realize the solution is an exact duplicate of #2504 (comment)

[davidszotten]

@carltongibson sorry for posting on an old issue, but i was wondering if you could link to a pr/ticket that's the source for you crossing out "Calling reverse is very expensive" as (Fixed in Django)

Thanks!

[rpkilby]

HI @davidszotten, see #3007 (comment).

[davidszotten]

HI @davidszotten, see #3007 (comment).

Thanks for the quick response! Maybe i'm missing something but isn't that about build_absolute_uri (as opposed to reverse)?

[rpkilby]

I guess the two are often used in conjunction with each other (e.g., when serializing hyperlinked models), so speeding up build_absolute_uri generally speeds up URL resolution. You're right that it doesn't look like the performance of reverse was improved.