¿Cómo probar y optimizar cuando no puede reproducir el entorno?

En el pasado, he trabajado en una variedad de entornos. Aplicaciones de escritorio, juegos, elementos integrados, servicios web, trabajos de línea de comandos, sitios web, informes de bases de datos, etc. Todos estos entornos compartían el mismo rasgo: sin importar su complejidad, sin importar su tamaño, siempre podría tener un subconjunto o una porción de la aplicación en mi máquina o en un entorno de desarrollo para probar.

Hoy no lo hago. Hoy me encuentro en un entorno cuyo enfoque principal es la escalabilidad. Reproducir el medio ambiente es prohibitivamente costoso. Tomar una porción del entorno, aunque sea plausible (algunas de las piezas tendrían que ser simuladas o utilizadas en un modo de instancia única para el que no están hechas), frustra un poco el propósito ya que oscurece la concurrencia y la carga que El sistema real se encuentra. Incluso un pequeño sistema de "prueba" tiene sus defectos. Las cosas se comportarán de manera diferente cuando tenga 2 nodos y cuando tenga 64 nodos.

Mi enfoque habitual para la optimización (medir, probar algo, verificar la corrección, medir las diferencias, repetir) realmente no funciona aquí, ya que no puedo hacer los pasos 2 y 3 de manera efectiva para las partes del problema que importan (solidez de la concurrencia y rendimiento bajo carga). Sin embargo, este escenario no parece único. ¿Cuál es el enfoque común para hacer este tipo de tarea en este tipo de entorno?

Hay algunas preguntas relacionadas:

• Esta pregunta tiene que ver con que el hardware (como los analizadores de espectro) no está disponible, lo que se puede emular (relativamente) fácilmente.
• Esta pregunta trata sobre la localización de errores que solo existen en entornos de producción, lo cual es útil, pero es un tipo diferente de actividad.

En realidad es difícil, pero estoy seguro de que en muchas situaciones comparables es principalmente un problema de organización. El único enfoque viable es probablemente una mezcla de medidas combinadas, no solo "una bala de plata". Algunas cosas que puedes probar:

• registro: como ya escribí en un comentario, el registro excesivo de tiempo y recursos (que es una especie de perfil) puede ayudarlo a identificar los cuellos de botella reales en la producción. Esto puede no decirle si una implementación alternativa funcionará mejor, pero seguramente lo ayudará a evitar optimizar la parte completamente incorrecta de su aplicación.

• pruebe lo que puede probar de antemano, a fondo, con mucha planificación inicial. Claro, las cosas se comportarán de manera diferente en la producción, pero no todas . La corrección de una implementación diferente a menudo se puede verificar de antemano; si una implementación se escala bien, es una pregunta diferente. Pero la planificación puede ayudar mucho. Piense detenidamente en los problemas que su entorno de prueba puede resolver por usted y cuáles no. Casi siempre hay cosas en las que cree a primera vista "no se puede probar de antemano", pero si lo piensa dos veces, a menudo hay más posibilidades.

• Trabaja en equipo. Cuando intente un nuevo enfoque o idea, discútalo con al menos otra persona de su equipo. Cuando implemente algo diferente, insista en las inspecciones de código y el control de calidad. Cuantos más errores y problemas pueda evitar de antemano, menos problemas graves tendrá que resolver en la producción.

• Como no puede probar todo de antemano, espere que aparezcan problemas en la producción. Por lo tanto, intente preparar una estrategia de respaldo realmente buena cuando ponga en producción un nuevo código. Cuando su nuevo código tiene el riesgo de ser más lento que la solución anterior, o si tiene el riesgo de fallar, asegúrese de que puede cambiar a la versión anterior lo antes posible. Si tiene el riesgo de destruir los datos de producción, asegúrese de tener una buena copia de seguridad / recuperación. Y asegúrese de detectar tales fallas agregando algún mecanismo de validación en su sistema.

• mantenga un diario del proyecto o un registro de la solución, en serio. Cada día descubres algo nuevo sobre el medio ambiente, escríbelo: historias de éxito y de fracaso. No cometas el mismo fracaso dos veces.

Entonces, la esencia es que, cuando no puede ir con la prueba y error, su mejor opción son técnicas conservadoras, clásicas de planificación inicial y control de calidad.

Si no puede reproducir el entorno en vivo, la incómoda realidad es que, haga lo que haga, no se habrá probado lo suficiente.

¿Entonces que puedes hacer?

Bueno, lo que sea que tenga que escalar, ya sea un proceso, un clúster de servidores o un volumen de base de datos, debe probarse con la regla de cero, uno e infinito en mente para descubrir dónde están los posibles cuellos de botella / limitaciones, ya sea IO, CPU, carga de CPU, entre otros. -proceso de comunicación, etc.

Una vez que tenga esto, debe tener una idea de qué tipo de prueba se ve afectada. Si se trata de pruebas unitarias, esto tradicionalmente corresponde al desarrollador, si se trata de pruebas de integración / sistema, entonces puede haber puntos de contacto con otros equipos que puedan ayudar con experiencia adicional o, mejor aún, con herramientas.

Hablando de herramientas, no es realmente la misión del desarrollador probar la carga de un sistema más allá de lo que es posible en su entorno de desarrollo. Esto debe ser enviado al departamento de pruebas u otro tercero.

¡El elefante en la sala, por supuesto, es que los sistemas no siempre se escalan de manera predecible!

En una vida anterior, era un DBA para bases de datos bancarias con miles de millones de filas y armado con planes de ejecución, generalmente podíamos predecir cuánto tiempo durarían las consultas en una base de datos inactiva dados los volúmenes de entrada. Sin embargo, una vez que estos volúmenes llegaran a un cierto tamaño, el plan de ejecución cambiaría y el rendimiento se deterioraría rápidamente a menos que se ajustara la consulta / base de datos.

Sugeriría experimentos.

El registro encontrará cuellos de botella. Luego puede probar una implementación alternativa en algunas máquinas, o incluso en todas las máquinas con una cierta probabilidad, o por un período de tiempo limitado. Luego, compare los registros nuevamente para buscar mejoras.

Es el mismo ciclo de teoría-experimento-medida al que está acostumbrado, pero es más costoso de configurar, ya que las hipótesis deben ejecutarse en la producción, y dependiendo de su volumen, la recepción de datos significativos de la producción también puede ser lenta.