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.