Hosting Capacity Results

This page records measured WebBlocks CMS capacity evidence. Read it with Hosting Capacity Validation: a partial qualification supports only the workload it actually ran.

Status: provisional core PHP-memory candidate and 24-megapixel media worker profile. This is not yet the complete MySQL production qualification because the core run used the package's SQLite feature-test environment and the operations and traffic profiles were not run.

The complete Feature suite ran in one PHP process: 567 tests and 3,076 assertions. This is deliberately more cumulative than an ordinary isolated HTTP request, but it is not a substitute for the production MySQL/HTTP fixture.

Under the protocol's 80% utilization rule, 101 MiB requires 126.25 MiB. Therefore 128 MiB is the current provisional core PHP memory_limit candidate. It becomes a production-certified minimum only after the corresponding Laravel consumer, MySQL 8.0, real HTTP, install, and representative content fixture pass.

The real MediaTransformService::regenerate() path generated all seven system variants from cold transform storage. Each source was 6,000 × 4,000 pixels (24 MP). The small compressed byte sizes do not weaken the decode-memory test: decoded pixel dimensions drive the dominant GD allocation.

The five WebP process peaks were 296.80, 310.20, 301.77, 312.26, and 300.96 MiB. All seven variants were generated in every run; measured transform time was 2.717–3.149 seconds. Applying the 20% margin to the 312.26 MiB worst case produces 390.33 MiB. The practical tested profile is therefore:

• PHP memory_limit: at least the provisional 128 MiB core candidate; and
• actual memory capacity: 512 MiB per simultaneously active PHP worker that may perform a 24 MP GD transformation.

The worker capacity is not the same as memory_limit. GD's native allocations were visible in process RSS but not in PHP's 32.5 MiB peak and were not stopped by memory_limit=128M. Total server RAM must additionally cover the operating system, web server, MySQL, caches, and other concurrent PHP workers.

Fixture checksums:

The CMS limits an uploaded media file to 50 MiB but does not currently limit raster pixel dimensions. Compressed file size does not provide a finite upper bound on decoded GD memory. Consequently:

• the 512 MiB media worker profile is qualified for the documented 24 MP fixture, not for every file below 50 MiB;
• no finite full-contract media memory maximum can be certified while raster dimensions are unbounded; and
• a product-owned maximum pixel count or width/height policy is required before the media profile can become a universal minimum.

Until that guard exists, hosting documentation must state the supported media workload beside the memory value. Operators accepting larger images need proportionally more worker memory or an external image-processing policy.

Before replacing “provisional” with “certified,” run and retain:

• a production-like Laravel 13 consumer on MySQL 8.0 through the real HTTPS/FPM path;
• the versioned core reference content fixture described by the validation protocol;
• install, backup, restore, site transfer, and package-native update profiles;
• disk low-water measurements and timeout measurements;
• traffic tests with declared worker concurrency; and
• a media rerun after a maximum raster-dimension contract is implemented.

The Hosting Readiness Checklist should reference the exact result profile selected for a deployment.