v0.10.0

The release that noticed the recommended shape does not run on defaults.

2 resolvers × 4 workers × 15 connections = 120
PostgreSQL default max_connections = 100 (97 after the superuser reserve)

Connections per process multiply by the worker count. The guide recommended that shape
without saying it jams there — and offered no way to tune the pool, leaving operators
to cut workers instead.

The knobs are there now, and the recommended values are only what the measurements call
for. No recommended value without a source.

Added

• Knobs for the connection pool (ARKHE_DB_POOL_SIZE, ARKHE_DB_MAX_OVERFLOW,
  ARKHE_DB_POOL_RECYCLE). On defaults, the shape this guide recommends does not run:

  2 resolvers × 4 workers × 15 connections = 120
  PostgreSQL default max_connections = 100 (97 after the superuser reserve)
  

  SQLAlchemy's default of pool_size 5 + max_overflow 10 = 15 per process multiplies by
  the worker count. Resolution is one short query (a primary-key index lookup,
  0.03 ms), so there is nothing to hoard — two or three per worker is usually enough.

  The defaults are unchanged, so behaviour is as before. Where something upstream drops
  idle connections, set ARKHE_DB_POOL_RECYCLE below that timeout: pool_pre_ping catches
  it, but spends a round trip every time it does.

• Recommended middleware settings in
  Deployment: the arithmetic for
  connection counts, PostgreSQL (shared_buffers sized to hold the indexes, work_mem
  left alone — resolution is one index lookup and almost nothing sorts or joins), worker
  counts, and a 1 MB request limit upstream (BULK_LIMIT is 1000 rows, and nginx's
  default client_max_body_size 1m is the edge).

  Only what the measurements call for. No recommended value without a source.

---

日本語の変更履歴
· Full Changelog: v0.9.2...v0.10.0