view release on metacpan or  search on metacpan

doc/problem-48-performance-research.md  view on Meta::CPAN

POD formatter. These gates validate the current code, not the open performance
target or release readiness.

## Current-checkout benchmark recheck (2026-10-15)

The existing Docker Template Toolkit benchmark was rerun with 21 alternating
samples, 1,000 request scopes per sample, five distinct-or-repeated renders per
scope, and exact rendered-body parity. The worker-local compiled-block cache
measured 0.0814 ms/render versus 0.2067 ms without reuse for repeated source,
and 0.0819 ms versus 0.2079 ms for five distinct sources (2.54x in both
workloads). The distinct sources recur across request scopes, confirming the
bounded worker cache's reuse across requests; this does not imply reuse for an
unseen source or establish whole-route performance.

Indicator listing was also measured in Docker with 21 alternating samples
and canonical JSON parity across two runtime layers. At 50 records, the
current path measured 1.278 ms versus 15.346 ms for the reconstructed legacy
path (12.01x); at 1,000 records, it measured 16.166 ms versus 240.010 ms
(14.84x). Root reuse explains nearly all of the gain: the current direct path
was only 1.03x and 1.04x faster than the intermediate root-reuse path,
respectively. These synthetic listing workloads are not dashboard-route or
per-subroutine comparisons. The all-subroutine 50x objective remains open.

The 5.95 tarball's blank-environment installation and integration gates are
complete: Docker cpanm installation passed all 277 bundled test files / 18,197
tests, and the documented blank-environment integration run passed.

The static-render and listing routines were rechecked on the current checkout
in Docker with exact output parity. Across 21 alternating runs of 1,000
renders, `PageRuntime::_render_templates`'s unchanged-body fast path took
0.00081 ms/render versus 0.07351 ms for the Template Toolkit compatibility
path (91.30x). This is a routine-specific microbenchmark, not a whole-route
comparison. Two-layer indicator listing across nine alternating runs measured
23.211 ms for the reconstructed legacy path versus 1.909 ms for the current
direct path at 50 indicators (12.16x), and 238.759 ms versus 16.372 ms at
1,000 (14.58x). The current direct path is not consistently faster than the
intermediate root-reuse path (0.96x at 50, 1.03x at 1,000). This confirms a
large win for static rendering and a workload-dependent list improvement; it
does not prove 50x against v5.88 for all subroutines.

## Problem 48 ASVS 5.0 applicability review (2026-10-15)

This review covers the performance work in the current Problem 48 change set,
not the repository's blanket compliance status. The relevant higher-trust work
is the OpenSSL PBKDF2 adapter and the native HTML escaper. Evidence includes
the full Docker suite and coverage gate, `t/651-crypto-pbkdf2-ffi.t`,
`t/665-problem48-xs-html-escape.t`, `t/667-problem48-collector-sync-roots.t`,
`t/668-problem48-status-response-cache.t`, and the web-security trio (466
assertions). ASVS Level 3 scrutiny was applied to authentication/cryptography
(V2/V6); other applicable chapters were reviewed at Level 2.

| Chapter | Applicability and evidence |
| --- | --- |
| V1 Architecture | Applicable: caches are bounded/scoped and preserve explicit freshness boundaries; direct route parity benchmarks and mutation tests. |
| V2 Authentication | Applicable, Level 3: PBKDF2 native adapter retains iteration count and Digest::SHA output; `t/651` checks native/Perl parity and unavailable/error paths. |
| V3 Session Management | No session lifecycle change; existing session and web-security tests pass in the complete suite. |
| V4 Access Control | No authorization rule change; protected-route/auth regressions remain green. |
| V5 Validation, Sanitization and Encoding | Applicable: XS escape paths preserve UTF-8/taint and match Perl output; `t/665` and static-file/security tests. |
| V6 Stored Cryptography | Applicable, Level 3: FFI inputs and OpenSSL ABI bounds are validated; native failure is visible; no reduced work factor or password-result cache. |
| V7 Error Handling and Logging | Applicable: failed native calls and filesystem I/O remain visible; warnings are fatal in tests; close and race failures have explicit assertions. |
| V8 Data Protection | Applicable: no cache persists credentials; status reuse retains high-resolution metadata checks and permission behavior is covered by existing tests. |
| V9 Communication | No transport/TLS behavior changed; `t/17-web-server-ssl.t` passed. |
| V10 Malicious Code | Applicable: XS is distribution-built C with no runtime compiler or shell execution; forbidden-import scan found no production imports/calls. |
| V11 Business Logic | Applicable: response reuse occurs only after unchanged config, inventory, and file-signature checks; changed persisted state is returned on the next request. |
| V12 Files and Resources | Applicable: paths derive from configured roots and discovered names; inventory changes, atomic replacement, missing roots, and I/O errors are tested. |
| V13 API and Web Service | Applicable: `/system/status` response caching preserves exact bytes and invalidates on persisted changes; web-security route tests passed. |
| V14 Configuration | Applicable: collector configuration signature invalidates cached work; current configuration remains authoritative and no new setting was introduced. |

Top 10 cross-check: A01/A07 access-control and identity rules were unchanged
and remain covered by auth tests; A02 cryptographic output and work factor
are pinned by `t/651`; A03 injection/encoding is covered by XS parity and web
tests; A04 design and A05 configuration by freshness/invalidations; A06/A08
dependency and build integrity by existing metadata/release tests; A09 by
visible error paths and logging tests; A10 SSRF is not newly applicable because
the changes add no network fetch or user-controlled destination. This is a
Problem 48 change review, not a claim that repository governance or release
gates are complete.

### Stable status-path string reuse (2026-10-15)

A current-checkout NYTProf profile ran 100 stable `/system/status` requests in
Docker with 50 configured collectors and exact 12,414-byte response parity.
The profile recorded 5,150 `Time::HiRes::stat` calls and 4,950
`File::Spec->catfile` calls for status paths. Per-file stat is required to
retain immediate visibility of external edits; repeatedly constructing the
same path string is not.

The red-first test in `t/667-problem48-collector-sync-roots.t` initially
observed 24 joins across two stable validations of 12 entries. The cache now
reuses path strings only when both ordered roots and the discovered directory
inventory match. A root or inventory change creates a new path map; file
metadata is still checked on every stable request. The focused Docker suites
pass 87 assertions, including malformed path-map recovery, file replacement,
inventory mutation, and missing-root cases.

For route-level impact, a 21-sample paired Docker run compared the production
path cache with an uncached control that discarded only the path-string map.
Each sample made 100 requests with 50 collectors; every route returned the
same 12,414-byte body. Median time changed from 72.341 ms per 100 requests to
66.347 ms (1.09x). This is a small incremental route gain, not an improvement
over v5.88 and not evidence for the full per-subroutine 50x objective.

Follow-up cache tests also cover absent and stale signatures and reject
malformed path lists. The full Docker coverage gate was rerun after these cases:
277 files and 23,938 tests passed, with statement, branch, condition, and
subroutine coverage all at 100.0% (48,462 detail rows; no stale uncoverable
annotations). This confirms coverage for the current tree; it does not change
the 1.09x route result or the still-open all-subroutine 50x objective.

After the gate, the `perldoc perlsec` frontend could not load a formatter in the
dev image, so the installed core `perlsec.pod` was read directly. The required
web security regression set passed 466 assertions across `t/08`, the static-file
suite, and `t/17`; repository scans were also run in Docker using `grep` because
the dev image does not contain `rg`.

## Saved-page profile and dashboard-root cache candidate rejected (2026-10-15)

A disposable Docker NYTProf run profiled 110 warm requests through the actual
`Web::App->handle('/app/welcome')` saved-page route with five saved nav
fragments. Each response returned 200, retained the page title and dynamic
stash marker, and measured 9,882 bytes. The profile attributed 11.068 ms over