Optimize DB queries for Events API end-point

[batpad]

Relates to #708

We should check the database queries being generated for the Events end-point, and use .select_related and .prefetch_related to reduce any excess queries.

In general, to do query profiling:

• Ensure Django Debug Toolbar is working, I just merged Django debug #682, we may need to test that it works under all local development scenarios.
• Once Django Debug Toolbar is working, you can visit an API end-point like
• Click on DjDT toolbar icon on the top-right of the page, and go to the Queries tab.

Inspecting the queries and SQL generated should give you a good idea if any of the related object lookups are being done in a loop instead of being fetched along-with the initial query.

To optimize, we'd add .select_related() and .prefetch_related calls to the ORM call in the get_queryset method for the view, and then one can re-inspect the queries in the Django Debug Toolbar to verify that the number of queries and overall query times have reduced.

get_queryset method of the View: https://github.com/IFRCGo/go-api/blob/develop/api/drf_views.py#L251

Django docs: https://docs.djangoproject.com/en/3.0/ref/models/querysets/#select-related

[GergiH]

@batpad I think this should cover it: #823 (already deployed to staging). What do you say I go around some other heavier ViewSets as well, like FieldReport and such, or should that be a different ticket?

[batpad]

@GregoryHorvath I had done some work on the FieldReport queryset, and that shouldn't be too terrible, though very likely can be further improved. It would be great to make separate tickets for each of the end-points.

I would very much be in favour of trying to deploy this sooner rather than later. It has no other dependencies and should just straight-up improve performance with very little risk.

Adding @karitotp as assignee to test: To Test that Export All for Emergencies works on staging, that the data returned is the same, and ideally feels "faster". If @karitotp gives a thumbs-up, let's discuss if we should deploy it during our call tomorrow.

[karitotp]

Hey @batpad, I gave a look to the exported csv of all emergencies and one for a filtered emergencies, the returned data match with the data in the staging, and I think the export is a bit faster, around 30 sec to export all emergency (3,907).

I only found one emergency https://dsgocdnapi.azureedge.net/api/event/3553/change/ that in the summary part has "éééééééééééé" but in the csv this looks weird:

[GergiH]

Hey @batpad,...

^ I found this is actually an issue with the Rich Text Editors saving accented characters like this:

As you can see it shows fine for the name. Looking into this.

[GergiH]

Separating the last comments into a new ticket since it's a separate issue. Thanks @karitotp nice find!

cc @batpad @nanometrenat

[tovari]

Testing passed on staging.