Convalida della capacità di hosting

Questo protocollo spiega come WebBlocks CMS stabilisce i requisiti di memoria PHP difendibili, tempo di esecuzione, caricamento e disco. Un valore diventa un minimo pubblicato solo dopo che il carico di lavoro di accettazione completo passa ripetutamente su un server di tipo produzione vincolato. Un'etichetta del pannello di controllo dell'hosting o un'installazione inattiva non costituiscono una prova.

Utilizzare questo protocollo quando si qualifica un piano di hosting e ogni volta che una versione CMS modifica sostanzialmente il comportamento di elaborazione multimediale, backup/ripristino, importazione/esportazione, installazione o aggiornamento.

I risultati della capacità sono specifici del carico di lavoro:

• profilo principale copre installazione, amministrazione, modifica delle pagine, pubblicazione e rendering pubblico senza trasformazioni GD o aggiornamenti nativi del pacchetto;
• profilo multimediale aggiunge il carico di lavoro dell'immagine di riferimento e le trasformazioni GD;
• il profilo operativo aggiunge backup delle applicazioni, prova di ripristino, trasferimento del sito e aggiornamento di sistema nativo del pacchetto; e
• il profilo di traffico misura la concorrenza separatamente dal runtime floor di richiesta singola.

Non comprimere questi profili in un numero inspiegabile. Ad esempio, un host condiviso solo core può essere valido anche se non soddisfa il profilo operativo, a condizione che la distribuzione, l'aggiornamento e il backup siano gestiti esternamente.

Eseguite l’artefatto della versione candidata in una nuova applicazione con la versione principale di Laravel supportata e usata nella distribuzione di destinazione, utilizzando la SAPI PHP di produzione, il server web, MySQL 8.0, il tipo di filesystem e le restrizioni dei processi dell’host di destinazione. Non usate il risultato del banco di prova SQLite del pacchetto come prova di idoneità dell’hosting.

Registrazione:

• Versioni CMS, Laravel, PHP, database, server Web e sistema operativo;
• Allocazione o limitazione della CPU, conteggio dei lavoratori PHP e tipo di archiviazione;
• PHP memory_limit, max_execution_time, upload_max_filesizee post_max_size sia per il web che per la CLI;
• e supporto codec GD;
• dimensioni dell'applicazione, del database, dei supporti e del backup prima di ogni esecuzione; e
• Stato della cache fredda/attiva e configurazione OPcache.

Creare una matrice di risorse invece di modificare più limiti contemporaneamente. Testare la memoria con limiti candidati decrescenti come 512, 256 e 128 MiB. Testare il tempo di richiesta in modo indipendente ai valori offerti da fornitori realistici. La cella di passaggio più bassa è un candidato, non ancora un minimo pubblicato.

Mantenere un dispositivo con versione e checksum registrato al di fuori del pacchetto di rilascio pubblico. Non dovrebbe contenere dati del cliente e dovrebbe creare almeno:

• 3 siti, 3 impostazioni internazionali, navigazione rappresentativa e relazioni Shared Slot;
• 250 pagine pubblicate e 50 bozze distribuite tra i tipi di blocco nativi;
• 5.000 blocchi, inclusi layout nidificato, galleria, navigazione, ricerca e contenuto del modulo;
• 500 record multimediali con almeno 2 GiB di originali totali per il profilo operativo;
• Immagini di riferimento JPEG, PNG con alfa e WebP, inclusi i casi verticale, orizzontale, con immagini piccole e con numero elevato di pixel;
• abbastanza revisioni, messaggi di contatto e record di ricerca per esercitare elenchi reali; E
• un pacchetto di dump del database e di trasferimento del sito generato dallo stesso stato.

Il manifesto dell'apparecchiatura deve registrare il numero di righe, le dimensioni dei byte, le dimensioni dell'immagine, i tipi MIME e i checksum SHA-256. La modifica dell'apparecchio avvia una nuova serie di benchmark; non confrontare silenziosamente i risultati di carichi di lavoro diversi.

Eseguire ogni scenario applicabile una volta come riscaldamento e poi cinque volte misurate. Tutti e cinque i cicli misurati devono superare.

1. Installa la versione in un consumer Laravel pulito ed esegui il flusso di installazione CMS.
2. Accedi, apri la dashboard, impagina e filtra la pagina più grande e gli elenchi dei media.
3. Crea, modifica, visualizza in anteprima, pubblica e richiedi pubblicamente una pagina nidificata rappresentativa.
4. Render della home page, una pagina ricca di contenuti, risultati di ricerca e navigazione localizzata.
5. Esegui la normale configurazione, percorso, visualizzazione e cancellazione della cache dell'applicazione.

1. Carica file immediatamente al di sotto del limite di convalida di 50 MiB del CMS tramite il percorso web HTTPS reale.
2. Carica ogni immagine raster di riferimento e genera ogni variante di sistema da una cache di trasformazione a freddo.
3. Rigenera il set completo di supporti di riferimento nel flusso di lavoro delimitato documentato.
4. Conferma il comportamento di fallback per un codec non supportato senza errori irreversibili o output incompleto.

Le immagini raster con un numero elevato di pixel sono più importanti per la memoria GD rispetto alle dimensioni dei file compressi. Il dispositivo multimediale quindi registra sia le dimensioni che i byte. Un limite di caricamento di 50 MiB non dimostra che ogni immagine compressa da 50 MiB possa essere trasformata entro un particolare limite di memoria.

1. Crea e scarica un backup completo dell'applicazione dal set di dati di riferimento.
2. Ripristinalo in una destinazione isolata e verifica i checksum del database e dei media pubblici.
3. esporta e importa il sito di riferimento con i file inclusi;
4. applicare la versione candidata tramite System Update nativo del pacchetto, incluso il backup pre-aggiornamento obbligatorio e l'area di lavoro di rollback; e
5. eseguire la pulizia e verificare che i backup conservati e le trasformazioni dei supporti correnti rimangano intatti.

Il test di ripristino distruttivo appartiene a una copia isolata, mai all'installazione di produzione.

Esegui un test di carico separato rispetto alle pagine pubbliche memorizzate nella cache e non memorizzate nella cache, oltre alle letture dell'amministratore autenticate. Indicare il mix di richieste, la concorrenza, la durata, il conteggio dei lavoratori, la dimensione del database e il driver della cache. Segnalare throughput e latenza; non convertire un risultato di concorrenza in un minimo di memoria PHP.

Raccogli prove lato server per ogni esecuzione:

• stato di uscita/HTTP ed errori di registro dell'applicazione;
• memoria di picco PHP per il lavoro CLI e memoria di picco del lavoratore o telemetria del provider per le richieste Web;
• durata e timeout dell'orologio da parete;
• errori del database e query lente;
• disco libero prima, disco libero minimo durante e disco libero dopo la pulizia;
• conteggi di output, integrità dell'archivio e checksum delle apparecchiature; E
• p50, p95 e latenza massima per il profilo di traffico.

Un profilo candidato passa solo quando:

• ogni operazione viene completata correttamente in tutte e cinque le corse misurate;
• non sono presenti errori di memoria insufficiente, timeout, caricamenti troncati, archivi parziali, errori di autorizzazione o nuove voci di registro a livello di errore;
• la memoria di picco misurata è al massimo l'80% di memory_limit;
• la durata misurata è al massimo l'80% del timeout di esecuzione applicabile;
• l'utilizzo del disco non entra mai nel margine di spazio libero riservato; E
• un ripristino pulito riproduce il database registrato e le prove del file.

Il margine di runtime del 20% assorbe la variazione ordinaria; non è un piano di capacità per la crescita del traffico. Se un candidato passa e il successivo candidato di livello inferiore fallisce, ripetere entrambe le celle in un secondo ambiente pulito prima di pubblicare il valore superato.

L'attuale richiesta multimediale CMS accetta al massimo 51.200 KiB (50 MiB) per file. Per esporre l'intero limite del prodotto, la SAPI Web e ogni proxy di fronte ad essa devono consentire la richiesta. upload_max_filesize deve essere almeno 50 MiB e post_max_size deve essere maggiore dell'intera richiesta in più parti. Una configurazione iniziale pratica è 64 MiB per entrambi i limiti, soggetta alla policy dell'applicazione host.

Ie una distribuzione sceglie intenzionalmente un limite di caricamento inferiore, documentarlo come limite di installazione; non modifica il tetto di validazione del CMS. Convalida i caricamenti appena al di sotto del limite scelto e il rifiuto appena al di sopra di esso. Testare tramite il percorso browser/API, poiché una copia del file system CLI ignora PHP e i limiti del corpo del proxy.

Esistono due diverse decisioni sul disco:

1. La capacità allo stato stazionario deve coprire i rilasci delle applicazioni, il database attivo, i supporti originali, le varianti generate, i registri, i file temporanei, i pacchetti di trasferimento del sito e la conservazione del backup configurato.
2. Il margine operativo deve coprire la maggiore sovrapposizione temporanea durante il backup, l'estrazione, l'aggiornamento, l'importazione o il rollback.

L'aggiornamento di sistema nativo del pacchetto attualmente applica un livello di preflight di spazio libero assoluto di 500 MiB. Questo è un cancello di sicurezza, non una promessa che 500 MiB siano sufficienti per un'installazione pesante. Per l'accettazione, misurare lo spazio libero più basso durante il profilo operativo e conservare almeno il maggiore tra:

• 500 MiB; oppure
• 125% del consumo massimo di disco temporaneo misurato per il set di dati di riferimento.

Dimensioni di memorizzazione in stato stazionario dai dati misurati:

Ricalcolare dopo la crescita materiale di supporti, dimensioni del database, conservazione del backup o dati del plug-in. Configura il monitoraggio per avvisare prima che venga consumato il margine operativo.

Archiviare il risultato grezzo con il record di qualificazione del rilascio e pubblicare un riepilogo in Risultati della capacità di hosting contenente il commit immutabile del CMS o il tag di rilascio, le versioni di qualificazione e dei dati di prova, una posizione stabile delle prove originali, il profilo del server, i limiti verificati, il caso peggiore di cinque esecuzioni, il margine e la data. Un minimo può essere modificato solo dopo una nuova serie di qualificazione riuscita. Se le prove originali non sono state conservate, indicatelo nel risultato e mantenete il profilo provvisorio.

Finché non esisterà quella serie, Requisiti di hosting deve indicare che il valore non è certificato dal prodotto. Una volta esistente, sostituisci l'istruzione con una tabella del profilo; mantieni la versione del carico di lavoro accanto a ogni numero in modo che cms.webblocksui.com non presenti una garanzia priva di contesto.

Utilizzare il Elenco di controllo della preparazione dell'hosting per allegare il profilo testato selezionato e le prove a una singola distribuzione.