Scope and purpose
ASAMB produces narrow, reproducible measurements of PHP runtime and web-systems implementation choices. The purpose is to create auditable local evidence, not universal product rankings or capacity forecasts.
Every report distinguishes measured behavior from operational recommendation. Correctness, security, interoperability and resource boundaries remain part of the decision.
Fixtures
Fixture data is generated deterministically in source code. Both variants in a study receive the same logical input. The report documents material semantic differences when the work cannot be fully interchangeable.
Fixtures are intentionally modest so the suite can rerun during deployment. Production teams should add application-specific workloads before making high-impact changes.
Warm-up and order
Each callable receives a short warm-up. Measured rounds rotate the variant order and reverse alternating rounds. This reduces, but does not eliminate, fixed ordering effects.
Garbage-collection cycles are requested before each measured variant. The suite does not clear operating-system file caches or control processor frequency.
Timing and statistics
Elapsed time uses PHP hrtime(true). The script divides each measured block by the operation count and publishes all resulting nanoseconds-per-operation samples.
The median is the primary value. The 25th and 75th percentiles describe the middle half of samples. Operations per second is derived from the median and should not be treated as an independently observed load-test result.
Environment capture
The publication records generation time, PHP version and SAPI, operating system, architecture, processor string when available, reported host memory, memory limit, selected extensions, clock and round count.
The environment is attached to every downloadable study file. A benchmark number copied without that context is incomplete.
Quality controls
The build fails when measurement data is absent or malformed. Report tables and charts are generated directly from the same JSON file distributed to readers.
Study-specific editorial text is stored separately from timing output. This allows data to be regenerated without silently rewriting the research question, cautions or limitations.
Rerun and correction policy
The suite should be rerun after runtime upgrades, host moves or material environment changes. Earlier files may be archived when longitudinal comparison matters.
Calculation errors, mismatched narrative or material methodology defects are handled under the public corrections policy.
Reproduction commands
php bin/benchmark.php --output=generated --rounds=7
php bin/build.phpThe installer runs these commands before deploying the static public directory.