Debugging Performance
summary
Profile-driven debugging of a Django app uses Blackfire probe+agent+browser companion to collect wall/cpu/io/memory dimensions, shows a model initializer called 6812 times, and surfaces a custom filter that loads every comment to count recent ones. Replacing that with a count query instead of loading all comments and then caching per-user status removes repeated work, removed 27 SQL queries, and drops page wall time from several seconds down to about 580 ms, with lower CPU and memory.
AI-written summary · about
chapters (15)
- 0:00Start
- 1:05Tracing and Sampling Profilers
- 2:51Pi Spy
- 3:10Trace Monologue
- 5:42The Agent
- 6:31Browser Extension
- 10:25Profile Summary
- 19:39Call Graph
- 20:36The Call Graph
- 21:41Critical Path
- 32:11Sql Queries
- 34:01Blackfire Recommendations
- 39:09Leverage Caching
- 41:25Premature Optimizations
- 41:44Guidelines for Debugging and Fixing Performance Issues
related talks
27mGetting Started with Profiling Laravel Code
28mThe life of a web request - techniques for measuring and improving Django application performance
17mOff the Beaten Path: Exploring Unusual Roads to Django Performance
52mUsing Blackfire to Profile Your Loading Time
45mCutting latency in half: What actually worked—and what didn’t
37mPerformant Django
31mHigh Performance Django
42mA Nice Problem to Have: Django Under Heavy Load