The document provides tips for optimizing Django applications. It recommends using update() instead of save() for thread safety, partitioning queries to avoid expensive joins that don't scale, caching querysets judiciously, and delaying creation of model instances until needed to reduce memory usage and improve performance. The author concludes by advertising open engineering positions at their company.

1. Tips & Tricks
Making Django play nice with your database

2. Save your changes
No really, make sure they’re actually saved
• save() isn’t thread safe
• update() works pretty well
• and is amazing for race conditions
• and counters

3. Atomic UPDATEs
Atomic updates are great for thread safety

4. Atomic UPDATEs
But we didn’t want to keep typing that out

5. QuerySets are heavy
• no identity mapper, duplicate rows
• django-idmapper can help
• instance creation is costly
• selects and joins are unoptimized
• joins dont scale

6. Partition your queries
Joins don’t scale, and are costly...

7. Partition your queries
... and so are keystrokes

8. Caching is bad?
QuerySet caching is nice, but not always wanted

9. Instances are expensive
Not all instances, mostly Django models
• Reddit comment model -- we pulled all
objects into memory
• Creation of thousands of instances when
we only need a small number

10. Instances are expensive
Here’s what we mean
Optimized to delay instance creation

11. Instances are expensive
Delaying creation until it was needed
700 µs
Average process time
525 µs
350 µs
175 µs
0 µs
800 25
Initial instances created
We didn’t even measure memory costs
(and yes, this chart IS useless)

12. Thanks
David Cramer
@zeeg
david@disqus.com
http://www.davidcramer.net
P.S. we’re hiring kickass Django engineers
(and some frontend guys too)

13. References & Stuff
• django-idmapper
http://github.com/dcramer/django-idmapper
• instance.update()
http://gist.github.com/550436
• attach_foreignkey
http://gist.github.com/550435
• SkinnyQuerySet
http://gist.github.com/550438