v0.33.0

docs/WEB_SERVER.md

@@ -20,6 +20,74 @@ A Web Service can be reused by several vhosts and one vhost can mix Web Server a
 
 The Web Server implementation is split under `src/web_server/` by responsibility. `mod.rs` is only the public facade; `config.rs` owns persisted/compiled service configuration, `filesystem.rs` owns document-root confinement and directory reads, `security.rs` owns Web Service hardening, `response.rs` owns static HTTP response/validator/range/listing behavior, `routing.rs` owns rewrites/`try_files`/precompressed selection, `fastcgi.rs` owns PHP-FPM/FastCGI, `serve.rs` owns request dispatch, and `htaccess.rs` owns the compatibility layer. Regression tests live in `tests.rs`. This keeps filesystem/security and FastCGI changes reviewable without growing another single Web Server source file.
 
+## Live Web Service diagnostics (0.33.0)
+
+Each configured Web Service card now contains an **expandable Live metrics**
+section with completed requests, responses/s, HTTP 5xx count, mean elapsed time
+until response headers, PHP request permits in use/limit, static/PHP/other response
+counts, delivered response body bytes and a compact per-service rate history.
+The section reuses the existing authenticated live status stream and is closed
+by default. Unconfigured/non-PHP services do not claim PHP worker capacity.
+
+**Overview** provides 12 additional opt-in Web Server blocks under
+**Settings -> Appearance -> Dashboard layout -> Overview cards**. All 12 are
+hidden by default, including when opening an older saved dashboard layout.
+They follow normal widget reordering, theme, card sizing and SSE updates.
+Sample history length is selectable as 60/120/300/600 points (temporary or
+browser-persistent), independently of Cache and Transform.
+
+The authenticated `/api/status` and compact `/api/status?view=live` payloads
+include `web_server_metrics`, keyed only by *configured Web Service ID*:
+
+```json
+{
+  "web_server_metrics": {
+    "site": {
+      "web": {
+        "requests": 120, "status_2xx": 100, "status_3xx": 5,
+        "status_4xx": 12, "status_5xx": 3,
+        "static_requests": 90, "php_requests": 25, "other_requests": 5,
+        "response_headers_us": 1500000, "response_bytes": 98000,
+        "active_headers": 0,
+        "methods": [110, 8, 0, 0, 2],
+        "selected_status": [95, 1, 3, 4, 8, 0, 2, 1],
+        "failures": [0, 0, 0, 0, 0, 0, 0, 0, 0],
+        "compression": [12, 1, 0, 0]
+      },
+      "php": {
+        "metrics": {
+          "requests": 25, "response_headers_us": 750000,
+          "response_bytes": 24000,
+          "failures": [0, 0, 0, 0, 0, 0, 0, 0, 0]
+        },
+        "capacity_limit": 32, "capacity_available": 24,
+        "capacity_used": 8
+      }
+    }
+  }
+}
+```
+
+The example is illustrative; the actual `php` object is `null` when PHP is
+not configured. Array orders: methods `GET, POST, PUT, DELETE, other`;
+selected statuses `200, 206, 304, 403, 404, 500, 502, 503`;
+FastCGI failures `capacity, connect_timeout, connect_error, request_timeout,
+request_io, response_timeout, response_io, invalid_response, body_io`;
+compression `gzip, br, zstd, deflate`.
+
+**Accounting semantics:** The response-kind counters describe the handler
+that produced the response; `other` covers early rejections not dispatched
+to a static file or PHP. `active_headers` means requests still awaiting their
+response headers, *not* live streaming body counts. Mean duration is until
+response headers are ready. Body-byte counters advance only when body frames
+are polled, **before final dynamic compression**; these are not network wire
+bytes. The compression counter records only the downstream encoder, not static
+precompressed `.gz`/`.br` sidecar selection. Failed PHP requests may count as
+both PHP responses and FastCGI failures. PHP permit capacity is RustProxy's
+configured request semaphore, *not* the number of processes in the external
+PHP-FPM pool. All counters are process/snapshot lifetime observations and may
+restart on a config publication.
+
 ## Dashboard configuration
 
 The Web Service editor is split into stable configuration tabs so later features do not create one long form: