←back to thread

149 points rbanffy | 1 comments | | HN request time: 0.201s | source
Show context
feydaykyn ◴[] No.42151073[source]
The snippets are not false, but there's so much context missing it's easy to worsen the situation, especially for beginners which seem to be the target audience.

First, this guide should emphasize the need to measure before doing anything : django silk, django debug toolbarsm, etc. Of course, measure after the optimizations too, and measure in production with an apm.

Second, some only work sometimes : select_related / prefetch_related / iterator will lead to giga SQL queries with nested joins all over the place, and ends by exploding ram usage. It will help at first, but soon enough one will pay any missing sql knowledge or naive relationships.

Third, caching without taking the context into account will probably lead to data corruption one way or another. Debugging stale cache issues is not fun, since you cannot reproduce them easily.

Fourth, celery is a whole new world, which requires workers, retry and idempotent logic, etc.

Finally, scaling is also about code: architecture, good practices, basic algorithm, etc

I'll end by linking to more complete resources : - https://docs.djangoproject.com/en/5.1/topics/performance/ - https://loadforge.com/guides/the-ultimate-guide-to-django-pe... - https://medium.com/django-unleashed/django-application-perfo...

replies(3): >>42155088 #>>42155739 #>>42156580 #
pastage ◴[] No.42155088[source]
> scaling is also about code

Which is darn hard if you are a beginner in a framework, loops in loops still bites me after reality does the integration test for me. This is especially true when you try to do a simple thing as a beginner. By scaling I am just talking about normal production, going from 2 developers to a couple of thousand customers.

replies(1): >>42155182 #
1. feydaykyn ◴[] No.42155182[source]
To mind it's a part where the Django guide could be expanded a bit, in order to help scaffold a simple but "open to the future" code architecture. For instance I would warn against fat models and propose a very light "service pattern" architecture