django-silk

django-silk is a profiling and inspection tool for Django applications that intercepts every HTTP request and the SQL queries it triggers, then exposes them through an in-app dashboard at /silk/. It layers a request/response-capturing middleware, a SQL execution wrapper, and a decorator/context manager for profiling arbitrary code blocks on top of Django’s existing request cycle, so teams can see exactly where time and queries go without standing up a separate APM stack.

Beyond passive capture, Silk supports dynamic profiling of code you don’t control — including third-party libraries — by monkey-patching target functions at runtime from settings, and it generates ready-to-run curl commands and Django test-client scripts for replaying any recorded request. It’s built for local debugging and staging environments where SQL-level visibility into a request matters more than production-grade APM overhead.

What You Get

• Request/response inspection UI showing timing, headers, bodies, and the number and duration of SQL queries per request
• SQL query analysis with per-query timing, stack traces back to the calling code, and optional EXPLAIN plan output
• A silk_profile decorator/context manager for profiling arbitrary functions or code blocks, including queries executed within them
• Dynamic profiling via settings that monkey-patches functions in code you don’t own (e.g. third-party libraries) without touching their source
• Auto-generated curl commands and Django test-client Python snippets for replaying any recorded request
• Configurable sampling rate, body-size limits, sensitive-key redaction, and authentication/authorization gating for the inspection UI

Common Use Cases

• Debugging a slow endpoint in staging by inspecting the exact SQL queries and timings behind a request
• Auditing a pull request for N+1 query problems using the per-request query count and SQL detail view
• Profiling a specific view or background task with @silk_profile() to isolate a cProfile breakdown to just that code path
• Instrumenting a third-party dependency at runtime via SILKY_DYNAMIC_PROFILING when forking it isn’t an option

Under The Hood

Architecture Silk is built as a standard Django middleware (SilkyMiddleware) that hooks process_request/process_response; a thread-local DataCollector singleton accumulates queries and profiles for the duration of a request, then bulk-writes them as Django ORM models (Request, SQLQuery, Profile) inside a database transaction once the response is ready. SQL interception works by monkey-patching Django’s SQLCompiler.execute_sql (silk.sql.execute_sql) so every query’s SQL text and timing is captured before finalisation. A separate profiling module provides the silk_profile decorator/context manager plus a dynamic runtime-patching module (profiling/dynamic.py) for instrumenting code that isn’t directly editable, and a code_generation module produces curl and Django test-client replay snippets per request. The app is organized into clearly separated concerns (models, views, middleware, collector, profiling, code_generation), though it leans on a thread-local Singleton as shared mutable state across the request lifecycle.

Tech Stack Pure Python/Django: setup.py declares Django>=5.2, sqlparse for SQL formatting, and gprof2dot for turning binary cProfile output into graph visualizations, with an optional ‘formatting’ extra pulling in autopep8 for pretty-printed code snippets. Packaging uses setuptools with setuptools_scm for git-tag-derived versioning. The UI’s static assets are built via a gulpfile.js/package.json toolchain (SCSS compilation, JS bundling), and views are rendered server-side through Django’s own template engine. The tox/CI matrix (tox.ini, .github/workflows/test.yml) exercises Python 3.10 through 3.15 against Django 5.2/6.0/6.1/main on SQLite, MySQL/MariaDB, and PostgreSQL, which is an unusually wide compatibility surface for a Django add-on.

Code Quality The project/tests/ directory holds well over twenty dedicated test_*.py modules covering the middleware, collector, models, code generation, dynamic profiling, and sensitive-data handling, run through pytest with coverage collection and reporting configured in pytest.ini. CI runs this suite across the full Python/Django/database matrix on every push and pull request, with coverage uploaded to Codecov, and flake8 is configured with a short, deliberate ignore list rather than being disabled. Error handling uses explicit custom exceptions (SilkNotConfigured, SilkInternalInconsistency) in most places, with a few narrowly-scoped broad excepts around known cProfile concurrency edge cases. No static type checking (mypy) is configured — the codebase relies on Django’s conventional dynamic-typing style rather than type hints.

API Design Integration is minimal: add the middleware, add ‘silk’ to INSTALLED_APPS, include the URLs, and migrate. The silk_profile decorator/context-manager API is idiomatic Django/Python and requires no extra boilerplate for basic use. The standout feature is SILKY_DYNAMIC_PROFILING, which lets a team profile third-party or otherwise unmodifiable code by monkey-patching named modules and functions purely from settings — a capability most profiling tools don’t offer. An extensive, well-documented SILKY_* settings surface (sampling percentage, body-size caps, sensitive-key redaction, EXPLAIN-plan analysis) gives fine-grained control without extra code, and per-request curl/Python replay generation meaningfully lowers the effort to reproduce a production issue locally.