El problema de One In, One Out

En CrowdHandler suele ser la primera pregunta que nos hacen. "¿Apoyan la función "One In, One Out"? Y la respuesta es, "sí, lo hacemos... pero, para la mayoría de los usuarios, no lo recomendamos".

Sabemos por experiencia que establecer simplemente la tasa de entrada adecuada es una forma más eficaz de gestionar el tráfico que "una entrada, una salida", y la mejor solución para la gran mayoría de nuestros clientes.

Lamentablemente, muchos propietarios de sitios web oyen "sí, apoyamos One In, One Out", pero no escuchan la segunda parte de nuestro consejo. Para ellos, el concepto de One In, One Out parece tan lógico que les resulta difícil imaginar que el tráfico se gestione de otra manera. Así que siguen adelante, comprueban la configuración de "una entrada, una salida" y se ponen en marcha... sólo para encontrarse con colas que se acumulan y usuarios que se quejan de la espera.

¿Qué tiene de malo "uno dentro, uno fuera"?

El problema es que la simplicidad de la fórmula "One In, One Out", tal y como la entendemos la mayoría de nosotros, no se corresponde con la realidad del tráfico web y los viajes de los usuarios. El umbral de "una entrada, una salida" puede ser tan irrelevante como problemático.

¿Irrelevante? Supongamos que tiene un sitio web con capacidad para 1.000 usuarios y que recibe 100 usuarios por minuto. Sabe que el recorrido medio de un usuario dura diez minutos, por lo que, partiendo de cero usuarios, se espera alcanzar la capacidad en diez minutos. Después de eso, si "Uno entra, uno sale" funcionara como muchos suponen que lo hace, la ecuación sería una simple 1000/10. El primer lote de 100 usuarios saldría en el minuto 10, momento en el que se permitiría la entrada de los 100 siguientes, y así sucesivamente.

Los que prestaron atención en clase de álgebra se habrán dado cuenta de que, a estas alturas, la variable de capacidad 1000 se ha anulado a sí misma. Podrías simplemente fijar la tasa de entrada en 100 y tendría exactamente el mismo efecto. 

Sin embargo, One In, One Out no es sólo irrelevante en este escenario. Es activamente problemático. Esto se debe a que la simple ecuación de "una entrada, una salida" también ignora dos factores cruciales: El tiempo de espera de la sesión y la capacidad de pago.

Primer problema: Tiempo de espera de la sesión

De acuerdo, el recorrido medio del usuario puede durar diez minutos. Pero bastantes usuarios nunca realizarán la compra, y si lo hacen, es posible que usted no lo sepa (a menos que configure el detección de salidas). Así que, en lugar de dejar que las sesiones de los usuarios se prolonguen y afecten potencialmente a la capacidad para siempre, las temporizamos.

El tiempo de espera de sesión por defecto de CrowdHandler es de 15 minutos, lo que significa que el lugar de cada usuario se mantendrá durante 15 minutos después de su última actividad. Esto permite a los usuarios tomarse un descanso, responder a un correo urgente o comparar precios rápidamente en otro sitio durante su visita, y volver a la cola sin tener que empezar de nuevo. 

Teniendo en cuenta esos 15 minutos, el recorrido medio real del usuario es de 25 minutos. Volviendo a nuestra ecuación, 1.000/25 significa que la tasa efectiva es de sólo 40 entradas y salidas por minuto si aplicamos el principio de "una entrada, una salida" a 1.000 usuarios. Utilizando nuestro cálculo original, esperaríamos que una cola de 3000 personas estuviera vacía después de 30 minutos con una espera media de 15 minutos. Pero si tenemos en cuenta el tiempo de espera de la sesión, los primeros 1.000 usuarios abandonarán la cola en los primeros 10 minutos y, a continuación, los 2.000 restantes se vaciarán a un ritmo de 40 por minuto, lo que supone 50 minutos. Así que la cola entera tardará una hora en vaciarse, con una espera media de 30 minutos. El doble de tiempo.  

“Ah!” you think. “But I won’t let the first 1000 users in at 100 per minute, I’ll maximise the rate and rely solely on One In, One Out to let the first 1000 users in in minute one, maximising my capacity”. Well, that’s a bad idea for two reasons, but the first is this:  Under One In, One Out, in our model scenario, the remaining 2000 users in the queue will not move at all for 25 minutes when the first checked out sessions start to expire. Those users will see a queue position that isn't moving, and a terrible wait time estimate. Just the kind of user experience you are trying to avoid. Furthermore, unless you are carefully accounting for session timeout in your One In, One Out threshold, you will actually have fewer checkouts over the long run, in addition to the stubborn queue.

Segundo problema: Capacidad de caja

Este problema se debe a otro malentendido: basar los ajustes de Una Entrada, Una Salida en prueba de carga de carga. 

Las pruebas de carga tienden a aumentar el tráfico de forma gradual (como si se estableciera una tasa en CrowdHandler) y a menudo modelan el tráfico diario, lo que supone que hay más visitantes navegando que comprando. Pero durante el lanzamiento de un producto o escenario de caídala proporción de compras será mucho mayor que la del tráfico normal. Usted debe suponer que la mayoría de los usuarios que usted pone en el inicio de un viaje de usuario va a comprobar a cabo en la primera oportunidad.

En muchos sentidos, no importa cuántos usuarios simultáneos crea que puede manejar su sitio. Lo que importa es cuántos pagos o transacciones puede gestionar por minuto. Mientras que muchos sitios pueden manejar 1000 usuarios concurrentes, muy pocos pueden procesar 1000 transacciones por minuto. Basar la configuración de Una Entrada, Una Salida en las métricas de usuarios concurrentes no tendrá en cuenta el pico de transacciones reales que se produce durante una caída o lanzamiento, y es más probable que el sitio se bloquee bajo la oleada de salidas que se producirá en el minuto 10 de nuestro escenario modelo, si deja entrar a 1000 usuarios en el minuto uno.

Una analogía útil es una tienda física con capacidad para 1.000 personas pero sólo 10 cajas registradoras. Aunque la tienda puede albergar cómodamente a 1.000 clientes, sólo puede procesar eficientemente 10 pedidos por minuto. Dejar entrar a 1.000 clientes a la vez sólo creará largas colas de gente frustrada, sin que se produzcan avances a medida que se acumulan las transacciones. Lo mismo ocurre en Internet, salvo que el riesgo no es sólo de largas colas, sino de caída de los servidores.

Cómo hacerlo bien

Una forma de mitigar los problemas con One In, One Out sería hacer algunos cálculos complicados durante la configuración. Esto podría implicar cosas como aumentar la capacidad de One In, One Out, reducir la configuración del tiempo de espera de la sesión, calcular los ratios de sesión y pago, asegurarse de que "Destruir sesión en el pago" está activado y calcular los tiempos reales de recorrido del usuario.

De hecho, nos entristeció tanto ver cómo los clientes saboteaban sus ventas con una mala configuración de One In, One Out, que añadimos un comprobador que intenta realizar estos cálculos y les muestra recomendaciones:

Para algunos clientes -aquellos para los que las sesiones simultáneas son realmente una métrica crítica de la aplicación; que están seguros de que entienden todos los resultados de sus pruebas de carga, y tienen una comprensión clara de los ajustes óptimos para los tiempos de espera de sesión y su impacto en el umbral de Una Entrada, Una Salida- estos cálculos pueden tener sentido. Si usted es ese cliente, le saludamos.

Pero, para la mayoría de los clientes, la respuesta es mucho más sencilla: olvídese de complicados cálculos basados en límites teóricos y pruebas de carga poco fiables, y céntrese en las métricas que realmente afectan a la experiencia del usuario. El éxito pasa por conocer el rendimiento máximo demostrado, no los hipotéticos usuarios simultáneos. 

Para la mayoría de los sitios, eso significa ajustar la tasa de entrada a un número un poco más alto que su tasa de pago máxima sostenible. (Un buen punto de partida es dividir por 60 el número máximo de pedidos que ha realizado en un periodo de una hora con éxito y, a continuación, ajustar la tasa un poco por encima de esa cifra). Esto permitirá un buen flujo de visitantes a su sitio.

Empiece de forma conservadora y controle de cerca el rendimiento. Si la cola se alarga pero el sitio se mantiene en buen estado, siempre puede aumentar la velocidad; la función de ajuste automático de CrowdHandler de CrowdHandler de CrowdHandler.

En resumen: centrarse en los resultados probados

Como estrategia de colas, puede parecer lógica, pero una interpretación simplista de "uno entra, uno sale" no tiene en cuenta los factores del mundo real en la ejecución. A menudo da lugar a problemas como largos tiempos de espera, clientes frustrados y cajas fallidas, porque los cálculos se basan en hipótesis: métricas poco fiables o poco realistas. 

Así que, aunque lo apoyamos, nuestro consejo es: no establezcas un umbral de Una Entrada, Una Salida sin entender exactamente lo que significa, y céntrate en tus tasas de pago por encima de las métricas de usuarios concurrentes. Si te centras en el rendimiento demostrado y en la realidad de los límites de tu sitio, mejorarás la experiencia de usuario para todos.