Django 性能监控与优化平台 · 埋雷对照与 AST 自动诊断 预览图

Django 性能监控与优化平台 · 埋雷对照与 AST 自动诊断

问题版与优化版同框对比、自写 SQL 采集中间件、AST 规则定位 N+1,附监控面板与压测报告

源码/项目包 v1.0 # Python# Django# 性能优化

这个项目解决什么问题

N+1 查询、无索引过滤、全表加载这类性能问题有个共同特点:不报错、不打日志,只有访问量上来之后才以"CPU 100%"的形式暴露,而且很难说清到底慢在哪。本项目不是讲理论,而是把完整证据链搭出来:一个故意埋了四类典型性能问题的"论坛"(问题版),一个逐项修复的对照版(优化版),再加上自研的采集中间件与诊断引擎——问题在哪一行、为什么慢、怎么修、修完快多少,全部落在数据和报告里。

核心亮点

  • 问题版 / 优化版同框对比:两个路由渲染同一个模板,功能完全一致,只有查询方式不同。页面底部实时显示 SQL 查询数与耗时,SQL 次数从"随帖子数线性增长"降到个位数,数字即证据。
  • 纯自研 AST 诊断规则引擎(核心创新):用 Python 标准库 ast 扫描视图源码,内置循环内查询(N+1 嫌疑)、未预取的外键访问、无 limit 的 all() 三条静态规则,再结合采集表的慢请求/慢查询数据做动态印证——不依赖任何外部 SaaS,每条结论都带问题位置、严重级别、推断原因和修复建议代码。
  • 自写采集中间件:通过 force_debug_cursor 捕获每个请求的 SQL(不依赖 DEBUG 开关),慢查询(>100ms)连同耗时一起写入 SQLite,面板与诊断引擎都吃这份数据。
  • 一份数据,多处可用:ECharts 监控面板(AJAX 自动刷新)、可导出的 Markdown 诊断报告、简版 Prometheus /metrics 端点、进程内基准压测对比表——Prometheus/Grafana 可接可不接,平台自身独立可用。

效果预览

监控面板的请求耗时趋势,问题版长期在告警线附近,优化版稳定在几十毫秒:

请求耗时趋势

自动诊断报告(静态扫描 R1-R3 + 动态指标 D1-D2),定位到 forum/views.py 的具体行号并给出修复片段:

诊断报告

预览图基于 init_data 模拟指标与演示代码的实际扫描结果排版,实际运行效果以平台页面为准。

你将学到

  • Django 性能问题的标准成因与修法:select_related / prefetch_related / annotate / LIMIT / 索引,以及它们为什么有效
  • 用一个中间件完成请求级性能采集(耗时、SQL 次数、慢查询落库)
  • 用标准库 ast 写静态分析规则:安全地遍历语法树、定位可疑模式、生成可解释的报告
  • 简版 Prometheus 文本格式的写法,以及 Grafana 面板的常用查询

适合谁

需要完成 Web 方向毕业设计、或想系统搞懂"Django 到底慢在哪"的学习者。难度 ★★★,代码注释齐全,四类性能问题都是真实生产环境的常见形态,不是造出来给人看的。


交付内容:完整可运行源码、README.md(逐步运行方法与实现说明)、requirements.txt。

许可:个人使用,可用于自己的学习、课程实验与研究报告,请勿转售或公开传播。

Python 3
Django 5.2
SQLite
ECharts 5/ matplotlib
Python 标准库 ast
django-debug-toolbar
silk
Prometheus + Grafana

环境与步骤

pip install -r requirements.txt
pip install -r requirements.txt
python manage.py migrate
python manage.py init_data          # 用户/帖子/回复 + 模拟监控指标
python manage.py runserver 8014     # 端口 8014

访问 /forum/problem/ 与 /forum/optimized/ 对比底部数字,再看 /monitor/ 面板与 /diagnose/ 诊断报告;压测可走 /benchmark/ 页面或 python manage.py run_benchmark。

Q:端口和各个入口在哪?

A:开发端口 8014。/forum/problem/ 是埋了四类性能问题的版本,/forum/optimized/ 是逐项修复的对照版,两者功能一致、只有查询方式不同,页面底部实时显示 SQL 条数与耗时;监控面板在 /,诊断在 /diagnose/,压测在 /benchmark/,Prometheus 指标在 /metrics。

Q:诊断是接了第三方 APM 吗?

A:不是,全部自研。中间件用 force_debug_cursor 捕获每个请求的 SQL(不依赖 DEBUG 开关)写入 SQLite;诊断引擎用标准库 ast 扫描视图源码,内置循环内查询(N+1 嫌疑)、未预取外键、无 limit 的 all() 三条静态规则,再用采集到的慢请求数据做动态印证,每条结论带问题位置、严重级别与修复建议代码。

Q:要先造数据吗?

A:要。跑 python manage.py init_data 生成帖子与回复,否则对比页没有可查询的数据量,SQL 条数从“随帖子数线性增长”降到个位数这件事就看不出来。

Q:django-debug-toolbar、silk、django-prometheus 要装吗?

A:不需要。它们在 requirements.txt 里是注释项,代码中一律 try-import:装了自动多出面板,不装不影响主流程。

购买评价(0)

暂无评价,购买后第一个来评价吧
相关商品
🍪 隐私提示 我们仅收集提供服务所必需的信息(详见《隐私政策》),不出售、不追踪。
¥109
立即购买