Pruebas de carga de una plataforma de trading antes del lanzamiento

¿Puede esta plataforma soportar el tráfico del día del lanzamiento? La respuesta útil se basa en una carga de trabajo medida, un límite operativo conocido y pruebas de que el servicio se recupera cuando falla un componente. Una prueba de inicio de sesión o un número elevado de solicitudes por sí solos no bastan para demostrarlo.

Una prueba de carga es un intento controlado de hacer que un sistema similar al de producción procese la actividad que se espera que reciba, para después observar dónde se ralentiza, se forman colas o falla. Para un broker o una prop firm, eso significa seguir las órdenes a través de la cadena real: conexión del cliente, autenticación, controles de riesgo, gestión de órdenes, puente o pasarela, y cualquier simulador de ejecución o conexión con el mercado. La ruta de los datos de mercado también importa. Una plataforma puede aceptar órdenes mientras las cotizaciones retrasadas, los precios obsoletos o las sesiones desconectadas la vuelven inutilizable.

Empiece por anotar qué decisión sobre el lanzamiento debe respaldar la prueba. Puede ser determinar si el servicio puede sostener un ritmo determinado de envío de órdenes durante una hora, o si puede volver a la normalidad después de perder una pasarela.

Decida qué límites son aceptables antes de ejecutar la prueba. Los ingenieros que comparan componentes y proveedores de plataformas pueden consultar la cobertura de Trading Technology sobre la infraestructura de brokers como referencia, pero la capacidad debe medirse con respecto a la carga de trabajo y la configuración propias de la firma.

Defina la carga de trabajo antes de elegir una herramienta

Un usuario virtual no es un modelo de carga de trabajo. Un usuario puede iniciar sesión, colocar una orden de mercado y salir. Otro puede mantener varias suscripciones de datos en streaming, modificar órdenes repetidamente y volver a conectarse después de una interrupción de la red. Modele los comportamientos que afectan al sistema, no solo el número de cuentas simuladas.

Utilice datos de producto y operaciones cuando existan: cuentas financiadas previstas, sesiones simultáneas, picos históricos de órdenes, combinación de instrumentos, horarios de sesión y suscripciones a datos de mercado. En el caso de un producto nuevo, haga explícitos los supuestos. Estime los usuarios activos a partir de los registros de lanzamiento, los supuestos de conversión y la proporción que probablemente estará en línea al mismo tiempo.

A continuación, modele por separado los periodos tranquilos y los picos concentrados. Un acontecimiento noticioso o la apertura del mercado pueden producir un pico breve varias veces superior al ritmo promedio.

Incluya las transacciones que consumen distintos recursos:

• Inicios de sesión, renovación de tokens y reconexiones de sesión, que pueden cargar los servicios de identidad y los grupos de conexiones.
• Solicitudes de alta, modificación y cancelación, con proporciones realistas de órdenes de mercado y órdenes pendientes.
• Controles de riesgo de margen, exposición, límites por símbolo y estado de la cuenta, incluidas las órdenes rechazadas.
• Suscripciones a datos de mercado y actualizaciones de cotizaciones salientes, agrupadas por popularidad de los instrumentos.
• Consultas de posiciones, historial de órdenes y saldos, que suelen afectar a las bases de datos o cachés de forma distinta a la entrada de órdenes.
• Desconexiones, reintentos y envíos duplicados, para poner a prueba la idempotencia y las rutas de recuperación.

Separe el ritmo de solicitudes del número de sesiones conectadas. Diez mil conexiones inactivas pueden poner a prueba la gestión de sockets, pero dicen poco sobre el volumen de órdenes.

Por el contrario, unos cientos de sesiones muy activas pueden saturar un servicio de riesgo. Especifique el tiempo de espera entre acciones de usuario, el tamaño de las cargas útiles, la combinación de protocolos y la distribución de la actividad entre cuentas. Un generador de ciclo cerrado espera una respuesta antes de enviar la siguiente acción, por lo que puede ocultar la sobrecarga al reducir su propio ritmo. Un generador de ciclo abierto envía a un ritmo fijo y revela el crecimiento de las colas, pero necesita controles para evitar saturar el entorno de pruebas sin registrar la causa.

Construya una prueba representativa, no una victoria sintética

Utilice versiones de software, configuración, formatos de mensajes y rutas de red similares a los de producción. Reproduzca los límites clave: grupos de subprocesos y conexiones, índices de bases de datos, tamaños de caché, límites de velocidad y descriptores de archivos.

Si el entorno de producción tiene un balanceador de carga en la nube, inspección de cortafuegos o una pasarela FIX, inclúyalo o documente la diferencia. Una prueba en un clúster de preproducción sobredimensionado dará cifras tranquilizadoras que no se corresponderán con el lanzamiento.

No dirija tráfico sin control a un proveedor de liquidez, mercado o servicio de pagos en producción. Utilice un simulador o un punto de conexión de prueba contratado, con límites explícitos para el ritmo de mensajes y el valor de las órdenes. Elimine los datos personales, pero conserve los campos y las distribuciones que afectan a los planes de consulta, las reglas de riesgo y el enrutamiento.

Las cuentas de prueba deben abarcar distintos usos, márgenes, instrumentos y permisos. Una única cuenta sin incidencias no es representativa.

Las cifras siguientes son rangos habituales de planificación para una prueba de una plataforma de broker minorista o prop, no niveles de servicio universales ni resultados auditados. Las cifras reales varían según la arquitectura, el número de instrumentos, el protocolo y el diseño de los datos de mercado. Utilícelas para comprobar si el plan de pruebas se sitúa en un orden de magnitud plausible y, después, fije objetivos a partir de las previsiones y la tolerancia al riesgo propias de la firma.

Son rangos amplios, no criterios para aprobar el lanzamiento. Por ejemplo, un servicio de datos de mercado que envía menos mensajes puede verse limitado por un pequeño grupo de símbolos con muchas suscripciones. Un uso promedio bajo de CPU también puede ocultar un trabajador saturado o un grupo de conexiones a la base de datos al límite. Registre mediciones por servicio e instancia, no solo un promedio de toda la plataforma.

Ejecute la prueba por etapas controladas

Acuerde una ventana de prueba, un responsable para cada sistema y una condición de parada antes de generar tráfico. Avise a los equipos de red, bases de datos, seguridad y soporte.

Mantenga abierto un canal de comunicación independiente y asegúrese de que la prueba pueda detenerse sin depender del servicio que se está probando. La siguiente secuencia proporciona a los operadores pruebas en pasos manejables.

1. Valide el sistema de pruebas. Ejecute una carga pequeña y compare los recuentos del lado del generador con los registros del servidor. Compruebe los relojes, los identificadores de solicitud, el análisis de respuestas y la clasificación de errores. Si el generador está limitado por la CPU, el resultado de la plataforma no es válido.
2. Establezca una referencia. Registre la latencia, el volumen de transacciones, las tasas de error, la profundidad de las colas, la CPU, la memoria, el uso de la red, las esperas de la base de datos y las tasas de aciertos de la caché con una actividad ligera. Incluya los mismos paneles y registros previstos para las operaciones de lanzamiento.
3. Aumente la carga por etapas. Aumente gradualmente las sesiones y el ritmo de solicitudes, por ejemplo en incrementos de 20% a 30%, y mantenga cada nivel el tiempo suficiente para que se estabilicen las colas y las cachés. Compare la carga generada con las transacciones completadas; el ritmo de envío del generador no demuestra que el trabajo se haya completado.
4. Pruebe el pico previsto y un margen de seguridad. Un método habitual de planificación es probar con aproximadamente 1.5 a 2 veces el pico previsto y comprobar después si el servicio se degrada de forma predecible. El margen no sustituye a una previsión y puede ser demasiado alto o demasiado bajo para un producto concreto.
5. Aplique un pico repentino. Aumente bruscamente la actividad en cuestión de segundos, en lugar de utilizar solo un incremento gradual. Esto permite detectar retrasos en el autoescalado, avalanchas de conexiones, límites de cola y comportamiento de limitación del tráfico. Incluya reconexiones tras una interrupción simulada de la red.
6. Realice una prueba de resistencia prolongada. Mantenga una carga representativa durante varias horas, a menudo 4 a 12 en un ejercicio previo al lanzamiento. Observe el crecimiento de la memoria, las fugas de conexiones, el volumen de registros, la presión sobre el almacenamiento y la acumulación lenta de trabajo en la base de datos.
7. Ponga a prueba los fallos y la recuperación. Retire un trabajador, una pasarela o una réplica de la base de datos mediante un método aprobado. Compruebe qué ven los clientes, si las órdenes se duplican o se pierden, cuánto tarda la recuperación y si el trabajo en cola se procesa sin provocar una segunda sobrecarga.

No cambie varios ajustes de capacidad a la vez. Si una prueba falla, conserve la carga de trabajo y cambie un factor, como el número de trabajadores o el tamaño del grupo de conexiones. De lo contrario, un mejor resultado no permitirá saber qué cambio fue determinante. Guarde los scripts de prueba, la configuración, los identificadores de compilación y los paneles junto con los resultados para poder repetir la prueba tras una corrección.

Establezca un criterio de lanzamiento a partir del comportamiento observado

El volumen de transacciones es solo un factor de la decisión. Revise las distribuciones de latencia, no solo los promedios.

Un tiempo de respuesta p95 o p99 muestra lo que experimentan las solicitudes más lentas; una media saludable puede coexistir con una cola larga causada por la contención de bloqueos o la recolección de basura. Registre cada límite importante con marcas de tiempo y distinga entre la confirmación interna de una orden y la confirmación de ejecución. Un mercado externo lento no debe clasificarse erróneamente como una plataforma lenta, y una confirmación rápida no debe presentarse como prueba de que se ha completado una operación.

Los operadores deben correlacionar los síntomas visibles para los usuarios con las señales de nivel de servicio. Un panel práctico para una prueba de lanzamiento suele incluir:

• Solicitudes enviadas, aceptadas, rechazadas, agotadas por tiempo de espera y reintentadas, por operación y servicio.
• Latencia P50, p95 y p99 para el inicio de sesión, la aceptación de órdenes, la cancelación y la entrega de datos de mercado.
• Profundidad de las colas y antigüedad del mensaje más antiguo en cada límite asíncrono.
• CPU, memoria, recolección de basura, rendimiento de la red, esperas de la base de datos y uso de los grupos de conexiones.
• Retraso de los datos de mercado, sesiones desconectadas, eventos de precios obsoletos y tasas de resuscripción.
• Tiempo de recuperación y número de órdenes conciliadas después de cada fallo provocado.

Acuerde los umbrales de fallo antes de la ejecución. Pueden incluir un tiempo máximo de aceptación de órdenes p99, una tasa de error tolerable, una cola que deba vaciarse en un intervalo determinado y la ausencia de pérdidas o duplicaciones de órdenes sin explicación. Estos valores dependen del producto. Una plataforma puede estar técnicamente disponible y aun así no superar la prueba operativa si el equipo de soporte no puede identificar las cuentas afectadas o conciliar el estado de las órdenes.

Deje constancia escrita del pico probado, del punto en que la latencia empezó a aumentar, del primer componente saturado y del comportamiento de recuperación. Si la capacidad alcanza su límite antes de la previsión, reduzca el alcance, añada capacidad o cambie el plan de lanzamiento y, después, repita la misma prueba. No considere que un panel en verde con un nivel de carga demuestra resiliencia. El criterio de lanzamiento debe indicar el límite probado, los supuestos en que se basa, las restricciones conocidas y quién acepta los riesgos restantes.

Los sistemas de trading suelen descubrir su minuto menos probado durante el más concurrido.

#pruebas de conmutación por error #pruebas de preparación para el lanzamiento #pruebas de carga de plataformas de trading #rendimiento de la plataforma del broker #capacidad de infraestructura de trading #pruebas del sistema de gestión de órdenes #prueba de carga de datos de mercado #prueba de estrés de plataformas de trading