Say downstream_timeout covers the connection and processing waits (closes #64)

The waits of up to 10 seconds for an upstream connection and for a
processing slot run inside downstream_timeout, and a request whose
downstream_timeout ends during one gets 500, not 503. The docs now say
so and advise keeping downstream_timeout longer than
upstream_fetch_timeout plus 20 seconds.

Model: opus-5-5

README.md

@@ -288,8 +288,9 @@ Key settings in more detail:
   bytes; default `52428800` (50 MiB). It also limits the image data pixa
   decodes
 - `downstream_timeout` — time allowed for answering one client request, as a
-  duration; default `60s`. The upstream fetch counts toward it, so keep it
-  longer than `upstream_fetch_timeout`
+  duration; default `60s`. The upstream fetch counts toward it, and so do the
+  waits for an upstream connection and for a processing slot (up to 10 seconds
+  each), so keep it longer than `upstream_fetch_timeout` plus 20 seconds
 - `signing_key` — HMAC secret for URL signatures
 - `cache_max_bytes` — disk cache size limit in bytes; `0` disables the
   disk cache entirely; omitted defaults to 75% of the free space on
@@ -298,12 +299,13 @@ Key settings in more detail:
   hosts together, on top of `upstream_connections_per_host`; default `64`. A
   fetch holds its connection until its image has been processed. A fetch that
   finds all of them in use waits up to 10 seconds for one to free up; if none
-  does, the request is answered 503 with the error
-  `server busy, try again later`
+  does, and `downstream_timeout` has not ended first, the request is answered
+  503 with the error `server busy, try again later`
 - `max_concurrent_processing` — the most images decoded and encoded at once;
   default the number of CPUs pixa can use (`GOMAXPROCS`), which follows a
   container's CPU limit. A request that finds all of them in use waits up to 10
-  seconds for one to free up; if none does, it is answered 503 the same way
+  seconds for one to free up; if none does, and `downstream_timeout` has not
+  ended first, it is answered 503 the same way
 
 See `config.example.yml` for all options with defaults.
 

config.example.yml

@@ -74,13 +74,14 @@ upstream_connections_per_host: 20
 # Maximum concurrent connections to all upstream hosts together, on top of
 # the per-host limit (default: 64). A fetch holds its connection until its
 # image has been processed. A fetch that finds none free waits up to 10
-# seconds for one, and if none frees up the request is answered 503.
+# seconds for one, and if none frees up the request is answered 503, unless
+# downstream_timeout has ended first.
 upstream_connections: 64
 
 # Maximum number of images decoded and encoded at once (default: the
 # number of CPUs pixa can use, which follows a container's CPU limit). A
 # request that finds none free waits up to 10 seconds for one, and if none
-# frees up it is answered 503.
+# frees up it is answered 503, unless downstream_timeout has ended first.
 # max_concurrent_processing: 4
 
 # Time allowed for one fetch from an upstream host (default: 30s)
@@ -90,8 +91,10 @@ upstream_fetch_timeout: 30s
 # (1 GiB) (default: 52428800, 50 MiB)
 upstream_max_response_size: 52428800
 
-# Time allowed for answering one client request, the upstream fetch
-# included, so keep it longer than upstream_fetch_timeout (default: 60s)
+# Time allowed for answering one client request (default: 60s). The
+# upstream fetch counts toward it, and so do the waits for an upstream
+# connection and for a processing slot (up to 10 seconds each), so keep it
+# longer than upstream_fetch_timeout plus 20 seconds.
 downstream_timeout: 60s
 
 # The origin a browser lets read pixa's responses, sent as the CORS