Bug description
While investigating slow performance on the /v2/creatures endpoint using Python's cProfile library, I discovered that the calls to the url() function were taking up a significant amount of server resources. When requesting a page of 50 creatures, 600+ calls to url(), taking up close to 40% of the server response time.
After some investigation, I believe that I have located the culprit:
class GameContentSerializer(serializers.HyperlinkedModelSerializer):
...
The GameContentSerializer is inherited but most/all of our other serializers and handles a lot of the API's features. This serializer in turn inherits from the DRF's HyperlinkedModelSerializer which extends the ModelSerializer which functionality to support easily generating URLs.
What I believe is happening on this endpoint is that Serializers that really don't need require a URL field, I am thinking of the Sumary serializers (DocumentSumarySerializer, SizeSumarySerializer, etc.), which were designed to serializer FKs on model views and designed to be as streamlined as possible, are generating their own URLs even when the URL is not being returned by the View.
So, hitting the /v2/creatures, every FK (document, document__publisher, size, creature_type, etc.) would be generating its own URL, which has become very expensive.
Proposed Solution
The best way to eliminate the unnecessary URL generation would be to:
- Refactor GameContentSerializer to inherit from
serializer.ModelSerializer instead of serializers.HyperlinkedModelSerializer to stop the automatic generation of URLs.
- [OPTIONAL] Explicitly add the
"url" field back onto serializers where it makes sense using a HyperlinkedIdentityField.
- Remove
"url" from serializer fields inheriting from GameContentSerializer
- Update tests to reflect new shape of API response
Bug description
While investigating slow performance on the
/v2/creaturesendpoint using Python'scProfilelibrary, I discovered that the calls to theurl()function were taking up a significant amount of server resources. When requesting a page of 50 creatures, 600+ calls tourl(), taking up close to 40% of the server response time.After some investigation, I believe that I have located the culprit:
The
GameContentSerializeris inherited but most/all of our other serializers and handles a lot of the API's features. This serializer in turn inherits from the DRF'sHyperlinkedModelSerializerwhich extends theModelSerializerwhich functionality to support easily generating URLs.What I believe is happening on this endpoint is that Serializers that really don't need require a URL field, I am thinking of the Sumary serializers (
DocumentSumarySerializer,SizeSumarySerializer, etc.), which were designed to serializer FKs on model views and designed to be as streamlined as possible, are generating their own URLs even when the URL is not being returned by the View.So, hitting the
/v2/creatures, every FK (document, document__publisher, size, creature_type, etc.) would be generating its own URL, which has become very expensive.Proposed Solution
The best way to eliminate the unnecessary URL generation would be to:
serializer.ModelSerializerinstead ofserializers.HyperlinkedModelSerializerto stop the automatic generation of URLs."url"field back onto serializers where it makes sense using aHyperlinkedIdentityField."url"from serializer fields inheriting fromGameContentSerializer