From 010f5031a71f5386ef779dcee64c840615883b31 Mon Sep 17 00:00:00 2001 From: Chris Meyers Date: Tue, 31 Aug 2021 16:17:48 -0400 Subject: [PATCH] grammar --- docs/debugging/debugging_slow_api.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/debugging/debugging_slow_api.md b/docs/debugging/debugging_slow_api.md index 519210aecf..cc89dc71cc 100644 --- a/docs/debugging/debugging_slow_api.md +++ b/docs/debugging/debugging_slow_api.md @@ -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 ```