PRNext prueba de resistencia: dos horas y 1,738 ediciones

#Una sesión con ediciones reales y navegadores reales.

La ejecución duró 7,201 segundos y aplicó 1,738 JavaScript y ediciones CSS. Cuatro pestañas de Chromium ejercitaron los accesorios App Router y Pages Router. Los errores de sintaxis intencionales interrumpieron la secuencia 28 veces para probar la recuperación.

Las comprobaciones del navegador conservaron un marcador de documento y el estado del componente, en lugar de considerar suficiente una respuesta HTTP 200. La carga de trabajo también verificó el orden de respuesta transmitido y el trabajo en segundo plano que accede al caché después de la respuesta.

El escenario también ejerció invocaciones de acciones del servidor 175. Cada respuesta tenía que pertenecer a la generación de aplicación esperada, en lugar de simplemente tener éxito en la capa de transporte. La recuperación de sintaxis tuvo que restaurar la página a una salida utilizable después de reparar la fuente, sin restablecer el estado en pestañas no relacionadas.

Cuatro pestañas del navegador, con documentos conservados y el estado de los componentes. 28 recuperaciones después de errores de sintaxis forzados. 174 streaming y 174 verificaciones de antecedentes/caché. Cero errores de página registrados por el arnés del navegador.

#Mida el árbol de servicios, no solo un proceso

El árbol de procesos de muestra incluía Node.js, esbuild y el servicio nativo Rust. Su tamaño de conjunto proporcional máximo fue 536.51 MiB. El crecimiento entre las ventanas de estado estacionario definidas fue 59.05 MiB, con como máximo diez procesos muestreados.

Estas lecturas se mantuvieron dentro de los presupuestos de recursos de la prueba. Son observaciones para este aparato, método de muestreo y máquina; no son un requisito de memoria universal ni una prueba de que no pueda existir ninguna fuga.

Contar solo el servicio nativo ocultaría el costo de los trabajadores JavaScript y los ayudantes del compilador. El tamaño del conjunto proporcional también representa la memoria compartida de manera diferente a una suma de lecturas del conjunto residente. Por lo tanto, el crecimiento máximo y en estado estacionario pertenecen a su método de muestreo cuando se compara otra serie con estos números.

#Sea explícito sobre la instantánea probada

La ejecución de dos horas utilizó una instantánea congelada antes de que se agregara la protección de límites del marco .mts/.cts final. Sus fuentes editadas fueron JavaScript y JSX. El último guardia recibió controles de regresión, embalaje y plataforma por separado, además de una carrera de humo más corta de cuatro pestañas.

Un monitor de retención de sistema de archivos auxiliar también tenía una brecha de muestreo 25-minute. Continuaron las comprobaciones principales del navegador y de la memoria. Mantener esos límites en el informe importa más que presentar un resultado ininterrumpido que nunca fue medido.

La distinción entre instantáneas es importante para correcciones sensibles a la seguridad. La guardia de límites posterior tiene su propia regresión pasajera y evidencia de ciclo de vida, pero esas comprobaciones no pueden cambiar retrospectivamente la fuente que se ejecutó durante dos horas. Llevar ambos registros permite entender exactamente lo que establece cada resultado.

#Lo que tomamos del resultado.

En esta carga de trabajo Linux x64, se retrasaron los presupuestos repetidos de edición, recuperación y recursos. Windows x64 recibió empaquetado, ciclo de vida y validación del navegador por separado. Las regresiones separadas del navegador también verifican la preservación del estado de los componentes predeterminados anónimos y las respuestas nuevas de la acción del servidor.

No valida macOS o ARM64, no reemplaza las pruebas específicas de la aplicación ni muestra una nueva ventaja de rendimiento sobre Next.js. Esas son preguntas separadas con medidas separadas.

Para una verificación específica de la aplicación, mantenga abiertas varias páginas representativas, interactúe con ellas antes de editarlas e incluya una falla de sintaxis intencional seguida de una reparación. Observe los errores del navegador y el árbol de procesos de servicio junto con la duración de la compilación. Esto prueba la continuidad del trabajo en lugar de reducir toda la sesión a su actualización más rápida.

Cómo comparar el rendimiento de React SSR

Alto uso de memoria Next.js: cómo diagnosticarlo

PRNext 0.1.18 versus Next.js: CPU, RAM y sueño