Résultats de capacité d’hébergement
Cette page enregistre les preuves de capacité WebBlocks CMS mesurées. Lisez-le avec Validation de la capacité d'hébergement : une qualification partielle prend en charge uniquement la charge de travail réellement exécutée.
2026-08-26 qualification de la mémoire locale
Statut : noyau provisoire PHP-mémoire candidate et profil de travailleur multimédia de 24 mégapixels. Il ne s'agit pas encore de la qualification complète de production MySQL car l'exécution principale a utilisé l'environnement de test de fonctionnalités SQLite du package et les opérations et les profils de trafic n'ont pas été exécutés.
Environnement
Article
Valeur
Identifiant de qualification
2026-08-26-local-v1
Source CMS
WebBlocks CMS v1.73.1, commit 464d20872a64c304ec4e440a6eb6f112fc9534ef
PHP
8.4.2 CLI, NTS
Harnais de test du cadre
Laravel 13 via PHPUnit 12.5.31
Système d'exploitation
Darwin 25.5.0, x86_64
Base de données pour l'exécution principale
SQLite :memory:
GD
Activé pour JPEG, PNG et WebP
Limite de mémoire initiale PHP
1 Gio ; processus contraint par enfant pour la matrice
Les résultats résumés et les sommes de contrôle des jeux de test ci-dessous ont été enregistrés, mais les journaux bruts des commandes et les fichiers d’échantillonnage des processus n’ont pas été conservés comme artefact immuable de qualification. Cette lacune constitue une raison supplémentaire de maintenir ce test à titre provisoire et de ne pas en faire un minimum certifié pour la production. Une nouvelle exécution de certification doit conserver ces fichiers bruts hors du paquet public et enregistrer ici leur emplacement stable.
Résultat de la suite de fonctionnalités de base
La suite complète de fonctionnalités s'est exécutée dans un seul processus PHP : 567 tests et 3 076 assertions. Ceci est délibérément plus cumulatif qu'une requête HTTP isolée ordinaire, mais cela ne remplace pas le dispositif de production MySQL/HTTP.
PHP memory_limit
Résult
Pic PHP signalé
Evidence
96 MiB
Échec
Limite épuisée
Échec pendant SiteCustomHeadApiTest après 453 tests terminés
112 MiB
Pass, un passage
101 MiB
Marge de sécurité de 20 %
128 MiB
Pass, cinq courses sur cinq
101 Mo chacun
Pire durée 39,505 secondes ; quatre exécutions ultérieures ont duré entre 33,146 et 33,267 secondes
Selon la règle d'utilisation de 80 % du protocole, 101 Mio nécessitent 126,25 Mio. Par conséquent, 128 MiB est le noyau provisoire actuel PHP memory_limit candidat. Il ne devient un minimum certifié en production qu'après la réussite du consommateur Laravel correspondant, de MySQL 8.0, du véritable HTTP, de l'installation et du montage de contenu représentatif.
Résultat de la transformation des médias
Le véritable chemin MediaTransformService::regenerate() a généré les sept variantes du système à partir du stockage par transformation à froid. Chaque source mesurait 6 000 × 4 000 pixels (24 MP). Les petites tailles d'octets compressés n'affaiblissent pas le test de décodage-mémoire : les dimensions des pixels décodés déterminent l'allocation GD dominante.
Format
Octets de luminaire
Pic signalé par PHP
Pic de processus observé RSS
JPEG
657,408
32,5 Mo
180,30 Mio
PNG
80,838
32,5 Mo
253,24 Mio
WebP
103,394
32,5 Mo
312,26 Mio, la pire des cinq exécutions mesurées
Les cinq pics du processus WebP étaient de 296,80, 310,20, 301,77, 312,26 et 300,96 Mio. Les sept variantes ont été générées à chaque exécution ; le temps de transformation mesuré était de 2,717 à 3,149 secondes. L'application de la marge de 20 % au pire des cas de 312,26 Mio produit 390,33 Mio. Le profil testé pratique est donc :
- PHP
memory_limit: au moins le candidat principal provisoire de 128 Mio ; et - capacité de mémoire réelle : 512 Mio par travailleur PHP actif simultanément pouvant effectuer une transformation GD de 24 MP.
La capacité du travailleur n'est pas la même que celle de memory_limit. Les allocations natives de GD étaient visibles dans le processus RSS mais pas dans le pic de 32,5 Mio de PHP et n'ont pas été arrêtées par memory_limit=128M. La RAM totale du serveur doit en outre couvrir le système d'exploitation, le serveur Web, MySQL, les caches et les autres serveurs PHP simultanés.
Sommes de contrôle des appareils :
Déposer
SHA-256
reference-6000x4000.jpg
a9fbf43349cc525164efb256aabde15c3f7fe86c4679400f5f982b4977696d83
reference-6000x4000.png
6e1876a3b91f63d1565822b448c9fbfc07e1e38bc21eb20c7c8d595fb68917e8
reference-6000x4000.webp
e3c8b2bbd4dfee01d64ca2380106ab18dc98acd82ee1eee9b5bb7ae1a269de3f
Limite de produit découverte par la mesure
Le CMS limite un fichier multimédia téléchargé à 50 Mo, mais ne limite pas actuellement les dimensions des pixels raster. La taille du fichier compressé ne fournit pas de limite supérieure finie sur la mémoire GD décodée. Par conséquent :
- le profil Media Worker de 512 Mio est qualifié pour le montage documenté de 24 MP, et non pour tous les fichiers inférieurs à 50 Mio ;
- Aucune quantité maximale de mémoire multimédia sous contrat complet ne peut être certifiée alors que les dimensions raster sont illimitées ; et
- Une politique de nombre maximum de pixels ou de largeur/hauteur appartenant au produit est requise avant que le profil multimédia puisse devenir un minimum universel.
Tant que cette protection n'existe pas, la documentation d'hébergement doit indiquer la charge de travail multimédia prise en charge à côté de la valeur de la mémoire. Les opérateurs acceptant des images plus grandes ont besoin proportionnellement de plus de mémoire de travail ou d'une politique de traitement d'image externe.
Travaux de qualification restants
Avant de remplacer « provisoire » par « certifié », exécutez et conservez :
- des applications Laravel 12 et 13 proches de la production sur MySQL 8.0, via le véritable chemin HTTPS/FPM ;
- l'appareil de contenu de référence de base versionné décrit par le protocole de validation ;
- profils d'installation, de sauvegarde, de restauration, de transfert de site et de mise à jour native du package ;
- mesures de manque d'eau sur disque et mesures de délai d'attente ;
- avec simultanéité de travail déclarée ; et
- une réexécution du média après la mise en œuvre d'un contrat de dimension raster maximale.
Le Liste de contrôle de préparation à l'hébergement doit faire référence au profil de résultat exact sélectionné pour un déploiement.