jazzband / django-silk

Silk Silk is a live profiling and inspection tool for the Django framework. Silk intercepts and stores HTTP requests and database queries before presenting them in a user interface for further inspection: Contents • Requirements • Installation • Features • Configuration • Authentication/Authorisation • Request/Response bodies • Meta-Profiling • Recording a fraction of requests • Limiting request/response data • Clearing logged data • Contributing • Development Environment Requirements Silk has been tested with: • Django: 4.2, 5.1, 5.2, 6.0 • Python: 3.10, 3.11, 3.12, 3.13, 3.14 Installation Via pip into a : To including optional formatting of python snippets: In add the following: **Note:** The order of middleware is sensitive. If any middleware placed before returns a response without invoking its , the won’t run. To avoid this, ensure that middleware preceding does not bypass or return a response without calling its . For further details, check out the Django documentation. **Note:** If you are using , place that **before** , otherwise you will get an encoding error. If you want to use custom middleware, for example you developed the subclass of , so you can use this combination of settings: To enable access to the user interface add the following to your : before running migrate: Silk will automatically begin interception of requests and you can proceed to add profiling if required. The UI can be reached at Alternative Installation Via github tags: You can install from master using the following, but please be aware that the version in master may not be working for all versions specified in requirements Features Silk primarily consists of: • Middleware for intercepting Requests/Responses • A wrapper around SQL execution for profiling of database queries • A context manager/decorator for profiling blocks of code and functions either manually or dynamically. • A user interface for inspection and visualisation of the above. Request Inspection The Silk middleware intercepts and stores requests and responses in the configured database. These requests can then be filtered and inspecting using Silk's UI through the request overview: It records things like: • Time taken • Num. queries • Time spent on queries • Request/Response headers • Request/Response bodies and so on. Further details on each request are also available by clicking the relevant request: SQL Inspection Silk also intercepts SQL queries that are generated by each request. We can get a summary on things like the tables involved, number of joins and execution time (the table can be sorted by clicking on a column header): Before diving into the stack trace to figure out where this request is coming from: Profiling Turn on the SILKY_PYTHON_PROFILER setting to use Python's built-in profiler. Each request will be separately profiled and the profiler's output will be available on the request's Profiling page in the Silk UI. Note that as of Python 3.12, cannot run concurrently so django-silk under Python 3.12 and later will not profile if another profile is running (even its own profiler in another thread). If you would like to also generate a binary file set the following: When enabled, a graph visualisation generated using gprof2dot and viz.js is shown in the profile detail page: A custom storage class can be used for the saved generated binary files: The default storage class is , and when using that you can specify a path of your choosing. You must ensure the specified directory exists. A download button will become available with a binary file for every request. This file can be used for further analysis using snakeviz or other cProfile tools To retrieve which endpoint generates a specific profile file it is possible to add a stub of the request path in the file name with the following: Silk can also be used to profile specific blocks of code/functions. It provides a decorator and a context manager for this purpose. For example: Whenever a blog post is viewed we get an entry within the Silk UI: Silk profiling not only provides execution time, but also collects SQL queries executed within the block in the same fashion as with requests: Decorator The silk decorator can be applied to both functions and methods Context Manager Using a context manager means we can add additional context to the name which can be useful for narrowing down slowness to particular database records. Dynamic Profiling One of Silk's more interesting features is dynamic profiling. If for example we wanted to profile a function in a dependency to which we only have read-only access (e.g. system python libraries owned by root) we can add the following to to apply a decorator at runtime: which is roughly equivalent to: The below summarizes the possibilities: Note that dynamic profiling behaves in a similar fashion to that of the python mock framework in that we modify the function in-place e.g: ,we would profile by dynamically decorating as opposed to : If we were to apply the dynamic profile to the functions source module **after** it has already been imported, no profiling would be triggered. Custom Logic for Profiling Sometimes you may want to dynamically control when the profiler runs. You can write your own logic for when to enable the profiler. To do this add the following to your : This setting is mutually exclusive with SILKY_PYTHON_PROFILER and will be used over it if present. It will work with SILKY_DYNAMIC_PROFILING. You can also use a . Code Generation Silk currently generates two bits of code per request: Both are intended for use in replaying the request. The curl command can be used to replay via command-line and the python code can be used within a Django unit test or simply as a standalone script. Configuration Authentication/Authorisation By default anybody can access the Silk user interface by heading to . To enable your Django auth backend place the following in : If is , by default S…