With any ORM, N+1 queries can be major performance problem. They can be a bit tricky to identify because individually the queries are fast, but when you execute N of them per request, it adds up. It’s worth looking at. You can write units tests that assert the number of actual SQL statements get executed for a given function. N+1 isn’t just a database issue either. I’ve seen N+1 at the cache level too with Redis. The cache layer supports ‘get_many’ and ‘set_many’.
I haven’t stood up a ‘fresh’ Django app in ages, but some things I remember are worth looking at:
* compression middleware like gzip. There is a big scary warning on this, but modern Django has mitigations in place
* how your DB connections are managed and reuse them- I think Django even supports a DB connection pool these days
* serve static assets directly - skip hitting Django for anything that isn’t dynamic
* compression middleware like gzip. There is a big scary warning on this, but modern Django has mitigations in place
* how your DB connections are managed and reuse them- I think Django even supports a DB connection pool these days
* serve static assets directly - skip hitting Django for anything that isn’t dynamic
reply