Hosting-Kapazitätsergebnisse

Auf dieser Seite werden gemessene WebBlocks CMS-Kapazitätsnachweise aufgezeichnet. Lesen Sie es mit Hosting-Kapazitätsvalidierung: Eine Teilqualifikation unterstützt nur die Arbeitslast, die sie tatsächlich ausgeführt hat.

Status: vorläufiger Kern PHP-Speicherkandidat und 24-Megapixel-Media-Worker-Profil. Dies ist noch nicht die vollständige MySQL-Produktionsqualifikation, da für den Kernlauf die SQLite-Funktionstestumgebung des Pakets verwendet wurde und die Vorgänge und Verkehrsprofile nicht ausgeführt wurden.

Artikel

Wert

Qualifizierungs-ID

2026-08-26-local-v1

CMS-Quelle

WebBlocks CMS v1.73.1, Commit 464d20872a64c304ec4e440a6eb6f112fc9534ef

PHP

8.4.2 CLI, NTS

Framework-Testumgebung

Laravel 13-Pakettestumgebung über PHPUnit 12.5.31

Betriebssystem

Darwin 25.5.0, x86_64

Datenbank für Kernlauf

SQLite :memory:

GD

Aktiviert für JPEG, PNG und WebP

Anfängliches PHP-Speicherlimit

1 GiB; pro untergeordnetem Prozess für die Matrix eingeschränkt

Die zusammengefassten Laufresultate und Fixture-Prüfsummen unten wurden aufgezeichnet; die rohen Befehlsprotokolle und Prozessmessdateien wurden jedoch nicht als unveränderliches Qualifizierungsartefakt aufbewahrt. Diese Beleglücke ist ein weiterer Grund, den Lauf als vorläufig einzustufen und nicht zu einer produktionszertifizierten Untergrenze zu erheben. Ein Zertifizierungslauf muss diese Rohdateien außerhalb des öffentlichen Pakets aufbewahren und ihren dauerhaften Speicherort auf dieser Seite dokumentieren.

Die komplette Feature-Suite lief in einem PHP-Prozess: 567 Tests und 3.076 Behauptungen. Dies ist bewusst kumulativer als eine gewöhnliche isolierte HTTP-Anfrage, aber es ist kein Ersatz für die Produktions-MySQL/HTTP-Fixture.

PHP memory_limit

Result

Gemeldeter PHP Spitzenwert

Evidence

96 MiB

Fail

Limit ausgeschöpft

Fehlgeschlagen während SiteCustomHeadApiTest nach 453 abgeschlossenen Tests

112 MiB

Pass, ein Lauf

101 MiB

Keine 20 % Sicherheitsmarge

128 MiB

Pass, fünf von fünf Läufen

101 MiB pro Stück

Schlechteste Dauer 39,505 Sekunden; vier aufeinanderfolgende Läufe dauerten 33,146–33,267 Sekunden

Unter der 80-%-Auslastungsregel des Protokolls erfordern 101 MiB 126,25 MiB. Daher ist 128 MiB der aktuelle vorläufige Kern-Kandidat PHP memory_limit. Es wird erst zu einem produktionszertifizierten Minimum, nachdem der entsprechende Laravel-Consumer, MySQL 8.0, echtes HTTP, die Installation und die repräsentative Inhaltsbefestigung bestanden wurden.

Der echte MediaTransformService::regenerate()-Pfad generierte alle sieben Systemvarianten aus der Kalttransformationsspeicherung. Jede Quelle hatte 6.000 × 4.000 Pixel (24 MP). Die kleinen komprimierten Bytegrößen schwächen den Decodierungsspeichertest nicht: Decodierte Pixelabmessungen steuern die dominante GD-Zuweisung.

Format

Fixture-Bytes

PHP-gemeldeter Peak

Oobservierter Prozesspeak RSS

JPEG

657,408

32,5 MiB

180.30 MiB

PNG

80,838

32,5 MiB

253.24 MiB

WebP

103,394

32,5 MiB

312,26 MiB schlechtester von fünf gemessenen Läufen

Die fünf WebP-Prozessspitzen betrugen 296,80, 310,20, 301,77, 312,26 und 300,96 MiB. In jedem Durchlauf wurden alle sieben Varianten generiert; Die gemessene Transformationszeit betrug 2,717–3,149 Sekunden. Die Anwendung der 20 %-Marge auf den ungünstigsten Fall von 312,26 MiB ergibt 390,33 MiB. Das praxiserprobte Profil lautet daher:

• PHP memory_limit: mindestens der vorläufige 128-MiB-Kernkandidat; und
• tatsächliche Speicherkapazität: 512 MiB pro gleichzeitig aktivem PHP Worker, der eine 24-MP-GD-Transformation durchführen kann.

Die Worker-Kapazität ist nicht dieselbe wie bei memory_limit. Die nativen Zuweisungen von GD waren im Prozess-RSS sichtbar, jedoch nicht im 32,5-MiB-Peak von PHP und wurden von memory_limit=128M nicht gestoppt. Der gesamte Server-RAM muss zusätzlich das Betriebssystem, den Webserver, MySQL, Caches und andere gleichzeitige PHP-Worker abdecken.

Fixture-Prüfsummen:

Datei

SHA-256

reference-6000x4000.jpg

a9fbf43349cc525164efb256aabde15c3f7fe86c4679400f5f982b4977696d83

reference-6000x4000.png

6e1876a3b91f63d1565822b448c9fbfc07e1e38bc21eb20c7c8d595fb68917e8

reference-6000x4000.webp

e3c8b2bbd4dfee01d64ca2380106ab18dc98acd82ee1eee9b5bb7ae1a269de3f

Das CMS begrenzt eine hochgeladene Mediendatei auf 50 MiB, begrenzt jedoch derzeit nicht die Rasterpixelabmessungen. Die komprimierte Dateigröße bietet keine endliche Obergrenze für den dekodierten GD-Speicher. Folglich:

• Das 512-MiB-Medienarbeiterprofil ist für das dokumentierte 24-MP-Gerät qualifiziert, nicht für jede Datei unter 50 MiB;
• Es kann kein begrenzter maximaler Medienspeicher für den gesamten Vertrag zertifiziert werden, während die Rasterabmessungen unbegrenzt sind. und
• Eine produkteigene Richtlinie zur maximalen Pixelanzahl oder Breite/Höhe ist erforderlich, bevor das Medienprofil zu einem universellen Minimum werden kann.

Bis dieser Schutz vorhanden ist, muss in der Hosting-Dokumentation neben dem Speicherwert auch die unterstützte Medienauslastung angegeben werden. Betreiber, die größere Bilder akzeptieren, benötigen proportional mehr Arbeitsspeicher oder eine externe Bildverarbeitungsrichtlinie.

Bevor Sie „provisorisch“ durch „zertifiziert“ ersetzen, führen Sie Folgendes aus und behalten Sie es bei:

• produktionsnahe Laravel-12- und Laravel-13-Host-Anwendungen auf MySQL 8.0 über den tatsächlichen HTTPS/FPM-Pfad;
• die vom Validierungsprotokoll beschriebene versionierte Kernreferenzinhaltskomponente;
• Installations-, Sicherungs-, Wiederherstellungs-, Standortübertragungs- und paketnative Aktualisierungsprofile;
• Datenträger-Niedrigwassermessungen und Timeout-Messungen;
• Verkehrstests mit deklarierter Worker-Parallelität; und
• eine Medienwiederholung, nachdem ein Vertrag mit maximaler Rasterdimension implementiert wurde.

Die Checkliste für die Hosting-Bereitschaft sollte auf das genaue Ergebnisprofil verweisen, das für eine Bereitstellung ausgewählt wurde.