Optimizing Django deployments with a Continuous Observability Strategy
summary
Shows how Blackfire.io plus Platform.sh turn production alerts into reproducible investigations by creating Git branch environments that mirror production profiling pinpoints the real bottleneck for a Django app for example a model call where set_attribute called 2500 times and uncached comment counting drives requests up, fixes include caching and switching to filtered counts, profiles compare before and after, and performance budgets are enforced with blackfire.yaml assertions so failing regressions block merges and let teams measure resource and carbon savings.
AI-written summary · about
chapters (8)
- 0:00Why optimize Django deployments
- 2:54Two key optimization needs
- 4:21Blackfire workflow overview
- 7:11Monitoring production issues
- 13:10Profiling performance bottlenecks
- 22:49Platform.sh for isolated testing
- 35:45Preventing regressions with tests
- 41:25Closing and Q&A
related talks
10mOptimizing Django deployments with a Continuous Observability Strategy
32mContinuous Deployment and Release of Django Apps
34mContinuous Deployment for webapps based on Django
21mHigh-Availability Django
32mOn the Care and Feeding of Feedback Cycles
34mGuide to Continuous Deployment with Rails
01h 12mPitfalls of Continuous Deployment
36mContinuous Deployment with Rails