Say downstream_timeout covers the connection and processing waits (closes #64)
check / check (push) Successful in 3m22s
check / check (push) Successful in 3m22s
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
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user