fix: cap Objecten/Objecttypen uWSGI to 1 worker — unstarve verify-stack e2e (closes #144) #145

2026-07-27T11:39:06Z

not commented

2026-07-27 11:39:06 +00:00

What & why

P0 — red main. Fixes #144: verify-stack fails on the Playwright e2e step (main runs 2177 after #142, 2190 after #143), while the PR runs passed.

Closes #144

Root cause

The Maykin Objecttypen (S-18a) and Objecten (S-18b) images run their web under uWSGI with 4 processes × 4 threads by default (UWSGI_PROCESSES:-4). Two web services × 4 idle Django workers (~200 MB each) sat idle during the e2e step and starved the single shared self-hosted runner — Keycloak and the portals stopped responding (the login #username never appeared) and Chromium hit Target crashed. The runner margin was already thin; the second chain tipped it over (main green through run 2159, red from 2177).

Fix

Cap UWSGI_PROCESSES: "1" + UWSGI_THREADS: "2" on both objecten and objecttypen in both compose files. These APIs only serve single-request smoke checks and are idle during e2e, so 1 worker is plenty — it frees ~1–1.5 GB. The -init containers ignore it (they run setup_configuration, not uwsgi).

Verified locally

Brought the objecten chain up with the cap: both services reach healthy, worker count drops from 6 (master + http + 4 workers) to 3 (master + http + 1 worker) per service, and make verify-objecten / make verify-objecttypen both still → OK — no-auth 401, token 200. docker compose config clean on both files.

Definition of Done

Linked issue (#144).
Conventional Commit referencing #144.
Verified locally (both APIs healthy + smoke green with 1 worker).
Closed by the merging PR (closes #144).

No ADR: config-only tuning of existing services — no boundary, dependency, or coupling change.

🤖 Generated with Claude Code

## What & why **P0 — red `main`.** Fixes #144: `verify-stack` fails on the Playwright e2e step (main runs 2177 after #142, 2190 after #143), while the PR runs passed. Closes #144 ### Root cause The Maykin **Objecttypen** (S-18a) and **Objecten** (S-18b) images run their `web` under uWSGI with **4 processes × 4 threads by default** (`UWSGI_PROCESSES:-4`). Two web services × 4 idle Django workers (~200 MB each) sat idle during the e2e step and starved the single shared self-hosted runner — Keycloak and the portals stopped responding (the login `#username` never appeared) and Chromium hit `Target crashed`. The runner margin was already thin; the second chain tipped it over (main green through run 2159, red from 2177). ### Fix Cap `UWSGI_PROCESSES: "1"` + `UWSGI_THREADS: "2"` on both `objecten` and `objecttypen` in both compose files. These APIs only serve single-request smoke checks and are idle during e2e, so 1 worker is plenty — it frees ~1–1.5 GB. The `-init` containers ignore it (they run `setup_configuration`, not uwsgi). ## Verified locally Brought the objecten chain up with the cap: both services reach healthy, worker count drops from 6 (master + http + 4 workers) to 3 (master + http + 1 worker) per service, and `make verify-objecten` / `make verify-objecttypen` both still → **OK — no-auth 401, token 200**. `docker compose config` clean on both files. ## Definition of Done - [x] Linked issue (#144). - [x] Conventional Commit referencing #144. - [x] Verified locally (both APIs healthy + smoke green with 1 worker). - [x] Closed by the merging PR (`closes #144`). No ADR: config-only tuning of existing services — no boundary, dependency, or coupling change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

not added 1 commit 2026-07-27 11:39:06 +00:00

fix(infra): cap Objecten/Objecttypen uWSGI to 1 worker — unstarve verify-stack e2e (closes #144 )

CI / build (pull_request) Successful in 1m26s

Details

CI / lint (pull_request) Successful in 1m38s

Details

CI / unit (pull_request) Successful in 2m18s

Details

CI / frontend (pull_request) Successful in 4m50s

Details

CI / mutation (pull_request) Successful in 7m14s

Details

CI / verify-stack (pull_request) Successful in 10m49s

Details

802f0e2c65

The Maykin images run uWSGI with 4 processes × 4 threads by default. Two
web services × 4 idle Django workers (~200 MB each) sat idle during the
Playwright e2e step and starved the single shared CI runner, so Keycloak
and the portals stopped responding (login never loaded) and Chromium
crashed — main verify-stack went red from run 2177 (post-#142) onward
while the PR runs passed on a less loaded runner.

These APIs only serve single-request smoke checks and are idle during
e2e, so 1 worker is plenty. Verified locally: both services healthy with
UWSGI_PROCESSES=1 and make verify-objecten / verify-objecttypen still green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not added the type:bug area:infra labels 2026-07-27 11:39:17 +00:00

not merged commit dd54688f86 into main

2026-07-27 13:07:56 +00:00

not referenced this pull request

2026-07-27 13:19:10 +00:00

S-18c · RegisterRecord objecttype defined + registered (closes #141) #146

not referenced this pull request

2026-07-27 14:07:47 +00:00

perf: cap OpenZaak + NRC uWSGI workers to shrink verify-stack footprint #147

not referenced this issue from a commit

2026-07-27 14:10:51 +00:00

perf(infra): cap OpenZaak + NRC uWSGI to 1 worker — shrink verify-stack footprint (closes #147)