Validation de la capacité d'hébergement

Ce protocole explique comment WebBlocks CMS établit des exigences défendables en matière de mémoire, de temps d'exécution, de téléchargement et de disque PHP. Une valeur ne devient un minimum publié qu'une fois que la charge de travail d'acceptation complète est passée à plusieurs reprises sur un serveur de type production contraint. Une étiquette du panneau de contrôle d'hébergement ou une installation inactive ne constitue pas une preuve.

Utilisez ce protocole lors de la qualification d'un plan d'hébergement et chaque fois qu'une version du CMS modifie matériellement le traitement des médias, la sauvegarde/restauration, l'importation/exportation, l'installation ou le comportement de mise à jour.

Les résultats de capacité sont spécifiques à la charge de travail :

• le profil principal couvre l'installation, l'administration, l'édition de pages, la publication et le rendu public sans transformations GD ni mises à jour natives des packages ;
• le profil multimédia ajoute la charge de travail de l'image de référence et les transformations GD ;
• le profil d'opérations ajoute des sauvegardes d'applications, une répétition de restauration, un transfert de site et une mise à jour système native du package ; et
• le profil de trafic mesure la concurrence séparément du plancher d'exécution à requête unique.

Ne réduisez pas ces profils en un seul numéro inexpliqué. Par exemple, un hôte partagé uniquement de base peut être valide en cas d'échec du profil d'opérations, à condition que le déploiement, la mise à jour et la sauvegarde soient gérés en externe.

Exécutez l’artefact de la version candidate dans une nouvelle application utilisant la version majeure de Laravel prise en charge et employée par le déploiement cible, avec la SAPI PHP de production, le serveur web, MySQL 8.0, le type de système de fichiers et les restrictions de processus de l’hôte cible. N’utilisez pas le résultat du banc de test SQLite du paquet comme preuve d’adéquation de l’hébergement.

Enregistrement :

• Versions CMS, Laravel, PHP, base de données, serveur Web et système d'exploitation ;
• Allocation ou limitation du processeur, nombre de travailleurs PHP et type de stockage ;
• PHP memory_limit, max_execution_time, upload_max_filesizeet post_max_size pour le Web et la CLI ;
• et prise en charge du codec GD ;
• tailles d'application, de base de données, de support et de sauvegarde avant chaque exécution ; et
• État du cache froid/chaud et configuration OPcache.

Créez une matrice de ressources au lieu de modifier plusieurs limites à la fois. Testez la mémoire aux limites candidates décroissantes telles que 512, 256 et 128 Mio. Testez le temps de demande de manière indépendante aux valeurs proposées par des fournisseurs réalistes. La cellule de réussite la plus basse est un candidat, mais pas encore un minimum publié.

Conservez un appareil versionné et enregistré avec une somme de contrôle en dehors du package de version publique. Il ne doit contenir aucune donnée client et doit créer au moins :

• 3 sites, 3 paramètres régionaux et une navigation représentative et des relations Shared Slot ;
• 250 pages publiées et 50 brouillons répartis dans les types de blocs natifs ;
• 5 000 blocs, y compris la mise en page imbriquée, la galerie, la navigation, la recherche et le contenu du formulaire ;
• 500 enregistrements multimédias avec au moins 2 Gio d'originaux au total pour le profil opérationnel ;
• Images de référence JPEG, PNG avec alpha et WebP, y compris les cas portrait, paysage, petites images et à nombre de pixels élevé ;
• suffisamment de révisions, de messages de contact et d'enregistrements de recherche pour exercer de véritables listes ; et
• un package de vidage de base de données et de transfert de site généré à partir de ce même état.

Le manifeste de l'appareil doit enregistrer le nombre de lignes, la taille des octets, les dimensions de l'image, les types MIME et les sommes de contrôle SHA-256. Changer de luminaire démarre une nouvelle série de références ; ne comparez pas silencieusement les résultats de différentes charges de travail.

RExécutez chaque scénario applicable une fois en guise d'échauffement, puis cinq temps mesurés. Les cinq analyses mesurées doivent réussir.

1. Installez la version dans un consommateur Laravel propre et exécutez le flux d'installation du CMS.
2. Connectez-vous, ouvrez le tableau de bord, puis paginez et filtrez les plus grandes pages et listes de médias.
3. Créez, modifiez, prévisualisez, publiez et demandez publiquement une page imbriquée représentative.
4. RAffiche la page d'accueil, une page riche en contenu, les résultats de recherche et la navigation localisée.
5. RExécutez la configuration normale, l'itinéraire, la vue et le cache de l'application de l'application.

1. Téléchargez les fichiers immédiatement en dessous du plafond de validation CMS de 50 Mio via le véritable chemin Web HTTPS.
2. Téléchargez chaque image raster de référence et générez chaque variante du système à partir d'un cache de transformation à froid.
3. Régénérez l'ensemble complet de supports de référence dans le flux de travail délimité documenté.
4. Confirmez le comportement de secours pour un codec non pris en charge sans erreur fatale ou sortie incomplète.

Les images raster à nombre de pixels élevé importent plus à la mémoire GD que la taille du fichier compressé. Le support multimédia enregistre donc les dimensions ainsi que les octets. Une limite de téléchargement de 50 Mio ne prouve pas que chaque image compressée de 50 Mio peut être transformée dans une limite de mémoire particulière.

1. Créez et téléchargez une sauvegarde complète de l'application à partir de l'ensemble de données de référence.
2. Restaurez-le dans une cible isolée et vérifiez les sommes de contrôle de la base de données et des médias publics.
3. exporter et importer le site de référence avec les fichiers inclus ;
4. appliquer la version candidate via la mise à jour système native du package, y compris son espace de travail de sauvegarde et de restauration obligatoire avant la mise à jour ; et
5. exécutez le nettoyage et vérifiez que les sauvegardes conservées et les transformations de support actuelles restent intactes.

Les tests de restauration destructive doivent être effectués sur une copie isolée, jamais sur l'installation de production.

Rexécutez un test de charge distinct sur les pages publiques mises en cache et non mises en cache ainsi que les lectures d'administrateur authentifiées. Indiquez la combinaison de requêtes, la simultanéité, la durée, le nombre de travailleurs, la taille de la base de données et le pilote de cache. Rapporter le débit et la latence ; ne convertissez pas un résultat de concurrence en un minimum de mémoire PHP.

Collectez des preuves côté serveur pour chaque exécution :

• état de sortie/HTTP et erreurs du journal des applications ;
• mémoire maximale PHP pour le travail CLI et mémoire de travail maximale ou télémétrie du fournisseur pour les requêtes Web ;
• durée de l'horloge murale et délais d'attente ;
• erreurs de base de données et requêtes lentes ;
• disque libre avant, disque libre le plus bas pendant et disque libre après le nettoyage ;
• décomptes de sorties, intégrité des archives et sommes de contrôle des appareils ; et
• p50, p95 et latence maximale pour le profil de trafic.

Un profil de candidat est retenu uniquement lorsque :

• chaque opération se termine correctement dans les cinq courses mesurées ;
• il n'y a pas d'erreurs de mémoire insuffisante, de délais d'attente, de téléchargements tronqués, d'archives partielles, d'échecs d'autorisation ou de nouvelles entrées de journal de niveau d'erreur ;
• La mémoire maximale mesurée est d'au plus 80 % de memory_limit ;
• la durée mesurée est au maximum de 80 % du délai d'exécution applicable ;
• l'utilisation du disque n'entre jamais dans la marge d'espace libre réservée ; et
• une restauration propre reproduit la base de données enregistrée et les preuves de fichiers.

La marge d'exécution de 20 % absorbe les variations ordinaires ; il ne s'agit pas d'un plan de capacité pour la croissance du trafic. Si un candidat réussit et que le candidat immédiatement inférieur échoue, répétez les deux cellules dans un deuxième environnement propre avant de publier la valeur de réussite.

La demande de média CMS actuelle accepte au maximum 51 200 Ko (50 Mio) par fichier. Pour exposer cette limite complète de produit, le Web SAPI et chaque proxy situé devant lui doivent autoriser la demande. upload_max_filesize doit faire au moins 50 Mio et post_max_size doit être supérieur à la totalité de la demande en plusieurs parties. Une configuration de départ pratique est de 64 Mio pour les deux limites, sous réserve de la politique de l'application hôte.

Si un déploiement choisit intentionnellement une limite de téléchargement inférieure, documentez-la comme limite d'installation ; cela ne modifie pas le plafond de validation du CMS. Validez les téléchargements juste en dessous de la limite choisie et les rejets juste au-dessus. Testez via le chemin du navigateur/API, car une copie du système de fichiers CLI contourne les limites de PHP et du corps du proxy.

Il existe deux décisions différentes en matière de disque :

1. Capacité stable doit couvrir les versions de l'application, la base de données active, les supports d'origine, les variantes générées, les journaux, les fichiers temporaires, les packages de transfert de site et la rétention de sauvegarde configurée.
2. Marge de fonctionnement doit couvrir le chevauchement temporaire le plus important lors de la sauvegarde, de l'extraction, de la mise à jour, de l'importation ou de la restauration.

La mise à jour système native du package applique actuellement un plancher de contrôle en amont absolu de 500 Mio d'espace libre. Il s'agit d'une barrière de sécurité, et non d'une promesse selon laquelle 500 Mio suffisent pour une installation gourmande en médias. Pour l'acceptation, mesurez l'espace libre le plus bas pendant le profil d'opérations et conservez au moins le plus grand des éléments suivants :

• 500 Mio ; ou
• 125 % de la consommation maximale de disque temporaire mesurée pour l’ensemble de données de référence.

Dimensionner le stockage en régime permanent à partir des données mesurées :

Recalculer après une croissance importante du support, de la taille de la base de données, de la conservation des sauvegardes ou des données du plug-in. Configurez la surveillance pour alerter avant que la marge de fonctionnement ne soit consommée.

Stocke le résultat brut avec l'enregistrement de qualification de version et publie un résumé dans Résultats de capacité d’hébergement comprenant le commit immuable du CMS ou l’étiquette de version, les versions de qualification et des jeux de test, un emplacement stable des preuves brutes, le profil du serveur, les limites testées, le pire résultat sur cinq exécutions, la marge et la date. Un minimum ne peut être modifié que par une nouvelle série de qualification réussie. Si les preuves brutes n’ont pas été conservées, indiquez-le dans le résultat et maintenez le caractère provisoire du profil.

Jusqu'à ce que cette série existe, Exigences d'hébergement doit indiquer que la valeur n'est pas certifiée par le produit. Une fois qu'elle existe, remplacez cette instruction par une table de profil ; conservez la version de la charge de travail à côté de chaque numéro afin que cms.webblocksui.com ne présente pas de garantie sans contexte.

Utiliser le Liste de contrôle de préparation à l'hébergement pour joindre le profil testé sélectionné et les preuves à un déploiement individuel.