Validación de capacidad de alojamiento

Este protocolo explica cómo WebBlocks CMS establece requisitos defendibles de memoria, tiempo de ejecución, carga y disco de PHP. Un valor se convierte en un mínimo publicado solo después de que la carga de trabajo de aceptación completa pasa repetidamente en un servidor de producción restringido. Una etiqueta del panel de control de hosting o una instalación inactiva no son evidencia.

Utilice este protocolo cuando califique un plan de alojamiento y siempre que una versión de CMS cambie materialmente el procesamiento de medios, la copia de seguridad/restauración, la importación/exportación, la instalación o el comportamiento de actualización.

Los resultados de capacidad son específicos de la carga de trabajo:

• el perfil principal cubre la instalación, administración, edición de páginas, publicación y renderizado público sin transformaciones GD ni actualizaciones nativas del paquete;
• el perfil multimedia agrega la carga de trabajo de imágenes de referencia y transformaciones GD;
• el perfil de operaciones agrega copias de seguridad de aplicaciones, ensayos de restauración, transferencia de sitios y actualización del sistema nativa del paquete; y
• el perfil de tráfico mide la simultaneidad por separado del piso de tiempo de ejecución de solicitud única.

No colapse estos perfiles en un número inexplicable. Por ejemplo, un host compartido de solo núcleo puede ser válido aunque falle el perfil de operaciones, siempre que la implementación, la actualización y la copia de seguridad se manejen externamente.

Ejecute el artefacto de la versión candidata en una aplicación nueva con la versión principal de Laravel admitida y utilizada en el despliegue de destino, usando la SAPI PHP de producción, el servidor web, MySQL 8.0, el tipo de sistema de archivos y las restricciones de procesos del alojamiento de destino. No utilice el resultado del entorno de pruebas SQLite del paquete como evidencia de alojamiento.

Registro:

• CMS, Laravel, PHP, versiones de base de datos, servidor web y sistema operativo;
• Asignación o limitación de CPU, recuento de trabajadores PHP y tipo de almacenamiento;
• PHP memory_limit, max_execution_time, upload_max_filesizey post_max_size tanto para web como para CLI;
• habilitó extensiones y compatibilidad con códec GD;
• tamaños de aplicaciones, bases de datos, medios y copias de seguridad antes de cada ejecución; y
• Estado de caché frío/cálido y configuración de OPcache.

Cree una matriz de recursos en lugar de cambiar varios límites a la vez. Pruebe la memoria en límites candidatos descendentes, como 512, 256 y 128 MiB. Pruebe el tiempo de solicitud de forma independiente con valores ofrecidos por proveedores realistas. La celda de aprobación más baja es candidata, aún no es un mínimo publicado.

Mantenga un dispositivo versionado y registrado con suma de verificación fuera del paquete de lanzamiento público. No debe contener datos del cliente y debe crear al menos:

• 3 sitios, 3 configuraciones regionales y navegación representativa y relaciones Shared Slot;
• 250 páginas publicadas y 50 borradores distribuidos en los tipos de bloques nativos;
• 5000 bloques, incluido diseño anidado, galería, navegación, búsqueda y contenido de formulario;
• 500 registros multimedia con al menos 2 GiB de originales totales para el perfil de operaciones;
• Imágenes de referencia JPEG, PNG con alfa y WebP, incluidos casos de retrato, paisaje, imagen pequeña y alto número de píxeles;
• suficientes revisiones, mensajes de contacto y registros de búsqueda para realizar listados reales; y
• un volcado de base de datos y un paquete de transferencia de sitio generado desde ese mismo estado.

El manifiesto del dispositivo debe registrar el número de filas, el tamaño de bytes, las dimensiones de la imagen, los tipos MIME y las sumas de comprobación SHA-256. Al cambiar el dispositivo se inicia una nueva serie de pruebas; No compare silenciosamente los resultados de diferentes cargas de trabajo.

Ejecute cada escenario aplicable una vez como calentamiento y luego cinco veces medidas. Deben pasar las cinco carreras medidas.

1. Instale la versión en un consumidor Laravel limpio y ejecute el flujo de instalación del CMS.
2. Inicie sesión, abra el panel, pagina y filtre las listas de medios y páginas más grandes.
3. Cree, edite, obtenga una vista previa, publique y solicite públicamente una página anidada representativa.
4. Representa la página de inicio, una página con mucho contenido, resultados de búsqueda y navegación localizada.
5. Ejecute la configuración normal, la ruta, la vista y el caché de la aplicación.

1. Cargue archivos inmediatamente por debajo del límite de validación de 50 MiB de CMS a través de la ruta web HTTPS real.
2. Cargue cada imagen ráster de referencia y genere cada variante del sistema desde una caché de transformación en frío.
3. Regenerar el conjunto de medios de referencia completo en el flujo de trabajo delimitado documentado.
4. Confirme el comportamiento de respaldo para un códec no compatible sin un error fatal o una salida incompleta.

Las imágenes rasterizadas con un alto número de píxeles son más importantes para la memoria GD que el tamaño del archivo comprimido. Por lo tanto, el dispositivo multimedia registra dimensiones además de bytes. Un límite de carga de 50 MiB no prueba que cada imagen comprimida de 50 MiB se pueda transformar dentro de un límite de memoria particular.

1. Cree y descargue una copia de seguridad completa de la aplicación desde el conjunto de datos de referencia.
2. Restaurarlo en un destino aislado y verificar las sumas de comprobación de la base de datos y los medios públicos.
3. exportar e importar el sitio de referencia con los archivos incluidos;
4. aplicar la versión candidata a través de la Actualización del sistema nativa del paquete, incluido su espacio de trabajo obligatorio de copia de seguridad previa a la actualización y reversión; y
5. ejecute la limpieza y verifique que las copias de seguridad retenidas y las transformaciones de medios actuales permanezcan intactas.

Las pruebas de restauración destructiva pertenecen a una copia aislada, nunca a la instalación de producción.

Ejecute una prueba de carga separada en páginas públicas almacenadas en caché y sin caché, además de lecturas de administrador autenticadas. Indique la combinación de solicitudes, la simultaneidad, la duración, el número de trabajadores, el tamaño de la base de datos y el controlador de caché. Informe de rendimiento y latencia; no convierta un resultado de simultaneidad en un mínimo de memoria PHP.

Recopile evidencia del lado del servidor para cada ejecución:

• estado de salida/HTTP y errores de registro de aplicaciones;
• memoria máxima PHP para trabajo CLI y memoria máxima de trabajador o telemetría de proveedor para solicitudes web;
• duración y tiempos de espera del reloj de pared;
• errores de bases de datos y consultas lentas;
• disco libre antes, disco libre más bajo durante y disco libre después de la limpieza;
• recuentos de salida, integridad de archivos y sumas de comprobación de dispositivos; y
• p50, p95 y latencia máxima para el perfil de tráfico.

Un perfil de candidato aprueba sólo cuando:

• cada operación se completa correctamente en las cinco corridas medidas;
• no hay errores de falta de memoria, tiempos de espera, cargas truncadas, archivos parciales, fallas de permisos o nuevas entradas de registro a nivel de error;
• la memoria máxima medida es como máximo el 80% de memory_limit;
• la duración medida es como máximo el 80% del tiempo de espera de ejecución aplicable;
• el uso del disco nunca ingresa al margen de espacio libre reservado; y
• una restauración limpia reproduce la base de datos registrada y la evidencia del archivo.

El margen de ejecución del 20% absorbe la variación ordinaria; no es un plan de capacidad para el crecimiento del tráfico. Si un candidato aprueba y el siguiente candidato inferior falla, repita ambas celdas en un segundo entorno limpio antes de publicar el valor de aprobación.

La solicitud de medios CMS actual acepta como máximo 51.200 KiB (50 MiB) por archivo. Para exponer ese límite total de productos, la web SAPI y cada proxy frente a ella deben permitir la solicitud. upload_max_filesize debe tener al menos 50 MiB y post_max_size debe ser mayor que toda la solicitud multiparte. Una configuración inicial práctica es 64 MiB para ambos límites, sujeta a la política de la aplicación host.

Si una implementación elige intencionalmente un límite de carga inferior, documentelo como límite de instalación; no cambia el límite de validación de CMS. Valide las cargas justo por debajo del límite elegido y el rechazo justo por encima. Pruebe a través de la ruta del navegador/API, porque una copia del sistema de archivos CLI omite PHP y los límites del cuerpo del proxy.

Hay dos decisiones de disco diferentes:

1. Capacidad en estado estacionario debe cubrir las versiones de aplicaciones, la base de datos activa, los medios originales, las variantes generadas, los registros, los archivos temporales, los paquetes de transferencia de sitios y la retención de copia de seguridad configurada.
2. Margen de operación debe cubrir la superposición temporal más grande durante la copia de seguridad, extracción, actualización, importación o reversión.

La actualización del sistema nativa del paquete actualmente impone un mínimo de verificación previa de espacio libre absoluto de 500 MiB. Esa es una puerta de seguridad, no una promesa de que 500 MiB sean suficientes para una instalación con muchos medios. Para la aceptación, mida el espacio libre más bajo durante el perfil de operaciones y conserve al menos el mayor de:

• 500 MiB; o
• 125% del consumo máximo de disco temporal medido para el conjunto de datos de referencia.

Tamaño del almacenamiento en estado estable a partir de datos medidos:

Recalcular después del crecimiento del material en medios, tamaño de la base de datos, retención de copias de seguridad o datos de complementos. Configure la supervisión para alertar antes de que se consuma el margen de operación.

Almacene el resultado sin procesar con el registro de calificación de la versión y publique un resumen en Resultados de capacidad de alojamiento que incluya el commit inmutable del CMS o la etiqueta de versión, las versiones de cualificación y de los datos de prueba, una ubicación estable de las evidencias originales, el perfil del servidor, los límites probados, el peor resultado de cinco ejecuciones, el margen y la fecha. Un mínimo solo puede cambiarse con una nueva serie de cualificación satisfactoria. Si no se conservaron las evidencias originales, indíquelo en el resultado y mantenga el perfil como provisional.

Hasta que exista esa serie, Requisitos de alojamiento debe decir que el valor no está certificado por el producto. Una vez que exista, reemplace esa declaración con una tabla de perfil; mantenga la versión de la carga de trabajo al lado de cada número para que cms.webblocksui.com no presente una garantía libre de contexto.

Utilice el Lista de verificación de preparación para el alojamiento para adjuntar el perfil probado seleccionado y la evidencia a una implementación individual.