External-Mirrors/awx
2
0
Fork 0
mirror of https://github.com/ansible/awx.git synced 2026-01-09 15:02:07 -03:30
Code Issues Packages Projects Releases Wiki Activity

grammar

Browse Source
This commit is contained in:
Chris Meyers 2021-08-31 16:17:48 -04:00
parent 8e043b139a
commit 010f5031a7
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/debugging/debugging_slow_api.md
View File

@ -5,7 +5,7 @@ The time it takes from the start of an HTTP request until the time the last byte
In practice, rarely is the network bandwidth or the client bandwidth the problem. The performance culprit usually involves the word "database". i.e. under-provisioned database hardware, low database IOPS (HD vs SSD vs NVME), a poor performing query, or many fast queries that add up to be slow. Rarely is it an inefficient python algorithm. Sometimes it is row-level database lock contention.
## Is it db related?
Every API response contains the headers `X-API-Time` and `X-API-Total-Time` where `X-API-Time` <= `X-API-Total-Time`. `X-API-Time` is set by the middleware function `TimingMiddleware.process_response()`. As of writing this `TimingMiddleware` appears very close to the top of the `MIDDLEWARE` settings list. Middleware `process_response` are processed in the reverse order, thus, `TimingMiddleware.process_response()` runs very close to the end of the middleware stack and therefore should result in `X-API-Time` =~ `X-API-Total-Time`. If `X-API-Total-Time - X-API-Time` is large then their is a performance problem in a small slice of code in between the middleware response processing and the DRF response processing. If `X-API-Total-Time` and `X-API-Time` are large then their is likely a performance problem and you need to enable `SQL_DEBUG` to determine if it is database related.
Every API response contains the headers `X-API-Time` and `X-API-Total-Time` where `X-API-Time` <= `X-API-Total-Time`. `X-API-Time` is set by the middleware function `TimingMiddleware.process_response()`. As of writing this `TimingMiddleware` appears very close to the top of the `MIDDLEWARE` settings list. Middleware `process_response` are processed in the reverse order, thus, `TimingMiddleware.process_response()` runs very close to the end of the middleware stack and therefore should result in `X-API-Time` =~ `X-API-Total-Time`. If `X-API-Total-Time - X-API-Time` is large then their is a performance problem in a small slice of code in between the middleware response processing and the DRF response processing. If `X-API-Total-Time` and `X-API-Time` are larger, then there is likely a performance problem and you need to enable `SQL_DEBUG` to determine if it is database related.
When `SQL_DEBUG = True` the headers `X-API-Query-Time` and `X-API-Query-Count` will be included in the response. A high `X-API-Query-Time` and `X-API-Query-Count` indicates there are many small queries that add up. A high `X-API-Query-Time` and low `X-API-Query-Count` indicates there are 1 or more expensive queries. A low `X-API-Query-Time` indicates you should look elsewhere (i.e. python algorithm or slow network).
@ -15,7 +15,7 @@ When `SQL_DEBUG = True` the headers `X-API-Query-Time` and `X-API-Query-Count` w
This is a useful tool for examining per-api endpoint SQL queries, performance, headers, requests, signals, cache, logging, and more.
To enable DDT, you need to set your `INTERNAL_IPS` to the IP address of your load balancer. This can be overridden by creating a new settings file beginning with `local_` in `awx/settings/` (e.g. `local_overrides.py`).
This IP address can be found by making a GET to any page on the browsable API and looking for a like this in the standard output:
This IP address can be found by making a GET to any page on the browsable API and looking for information like this in the standard output:
```
awx_1 | 14:42:08 uwsgi.1 | 172.18.0.1 GET /api/v2/tokens/ - HTTP/1.1 200
```