perf(uwsgi): set lazy-app = false so the master preforks the app (MAPCO-11223)

[razbroc]

Question	Answer
Bug fix	✔
New feature	✖
Breaking change	✖
Deprecations	✖
Documentation	✔
Tests added	✖
Chore	✔

Related issues: MAPCO-11223, MAPCO-11221 (sub-tasks of MAPCO-11217)

Stacked on #88. The base of this PR is feat/otel-postfork-init, so the diff shown here is only the config flip. Merge #88 first; GitHub will retarget this to master automatically. Do not merge this one alone — without the _init_telemetry() dispatch from #88, loading the app in the master leaves every worker sharing one set of provider objects and one inherited gRPC channel.

Further information:

What this does

One-line behavioural change in helm/config/mapProxyUwsgi.ini:

-lazy-app = true                      ; Fork workers after app load (required for OTel) todo check this variable effect
+; Load the app once in the master, then fork. Workers share the parsed mapproxy.yaml
+; copy-on-write. app.py builds the OTel providers in a postfork hook so their export
+; threads and gRPC channels are still created per worker — see src/app.py.
+lazy-app = false

The master now parses mapproxy.yaml once and forks workers from it, instead of each of the 6 workers parsing it independently. Also updates the corresponding readme row.

Note the comment being replaced described the opposite of the value it annotated — lazy-app = true means workers load the app after fork, not "fork workers after app load" — and carried a stale todo. That inversion is probably why this was never revisited.

Why the payoff is uncertain, and what I would want before merging

I want to be straight about this rather than let a green test imply more than it shows.

Measured RSS on the deployed test release with lazy-app = false:

Process	RSS
master	108.5 MiB
workers (x6)	78.5 / 78.7 / 78.9 / 78.5 / 78.8 / 78.9 MiB
total	472.2 MiB

There is no lazy-app = true arm to compare against. lazy-app is hardcoded in this ini rather than exposed as a Helm value, so a controlled A/B was not possible on the deployed chart. That is MAPCO-11224, and it is the reason that sub-task cannot be closed as a pass.

Worse for the motivation: worker RSS of ~79 MiB sits against a reload-on-rss = 2048 ceiling. Memory pressure does not appear to be an active problem here, so the copy-on-write saving may be worth very little in practice. Two further caveats on the numbers above — measurement was taken shortly after startup, which overstates CoW sharing before refcount churn erodes it, and CPython dirties shared pages as object refcounts change.

So the honest framing is: the correctness work in #88 stands on its own; this flip is an optimisation whose benefit is unquantified. A reviewer could reasonably ask to park this until lazy-app is a Helm value and the comparison exists. I would not object.

The startup cost is real and measured, though: 13 seconds for the master to load the WSGI app. That is a single serial load before any worker exists, where previously 6 workers loaded in parallel. Startup and liveness probe timing therefore needs a look — MAPCO-11225. For the record, harakiri is not relevant to this: it is a per-request timeout, not a startup timeout.

Deployment hazard worth knowing about

Testing this required installing the chart standalone rather than through the umbrella release. Two traps, both hit:

1. nginx.fullnameOverride collides with the shared raster-serving-dev-mapproxy-nginx-* resource names. A failed install attempt under the colliding name had its cleanup delete the live raster-serving-dev-mapproxy-nginx-route, and the replacement release then claimed tiles-dev.mapcolonies.net and pointed it at a service with no endpoints. That took the dev tile endpoint down with 503s until the route was restored from helm get manifest. Override the nginx fullname, and check oc get routes for host collisions before and after.
2. The vendored nginx-2.2.1 subchart has a literal tab in configMap: that breaks PyYAML parsing of the rendered manifest, and its nginx.conf subPath mount fails with CreateContainerError ("not a directory"). Pre-existing, not caused by anything in this repo, but it means the nginx container will not start in a standalone install — test against the app's http-socket on 8080 directly.

Testing

Deployed as an isolated release in raster-dev with this config. Load order from the logs:

[otel] imported in uWSGI master (lazy-app=false) - telemetry deferred to postfork hook
WSGI app 0 (mountpoint='') ready in 13 seconds on interpreter ... pid: 1
spawned uWSGI worker 1 (pid: 25) ... spawned uWSGI worker 6 (pid: 30)

Probe / TracerProvider / MeterProvider init lines then appear once per worker, 6x each — confirming providers are built per worker after the fork, not inherited. Worker pids are contiguous 25-30, the signature of a single prefork rather than six independent app loads.

Serving verified equivalent to the deployed v1.9.2: the same WMTS tile returned a byte-identical 2662-byte 256x256 RGBA PNG, and WMTS/WMS GetCapabilities both returned 200.

Unverified: spans landing in the collector backend (only absence of export errors was observed), the atexit flush on a real worker recycle, and cold-start-to-first-response end to end.