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
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
I don't think the article mentioned it but adjusting how you configure the WSGI server can really affect performance too.
It's also easy to accidentally make your DB queries sequentially or lazily. Using select_related is critical.