Cómo averiguar cuántos usuarios puede admitir mi aplicación sin fallar

Cuando se prueba la carga de una aplicación, el primer conjunto de pruebas debe centrarse en medir el rendimiento máximo. Esto es especialmente cierto en el caso de las aplicaciones interactivas para múltiples usuarios, como las aplicaciones web. El rendimiento máximo se mide mejor ejecutando algunos usuarios emulados con cero tiempo de reflexión. Esto significa que cada usuario emulado envía una solicitud, recibe una respuesta e inmediatamente regresa para enviar la siguiente solicitud. Aunque esto es artificial, es la mejor manera de determinar rápidamente el rendimiento máximo de la infraestructura del servidor.

Ley de Little

Una vez que tenga ese rendimiento (digamos X), podemos usar la Ley de Little para estimar el número de usuarios simultáneos reales que la aplicación puede admitir. En términos simples, la Ley de Little establece que:

N = X / λ

donde N es el número de usuarios concurrentes, λ es la tasa de llegada promedio y X es el rendimiento. Tenga en cuenta que la tasa de llegada es la inversa del tiempo entre llegadas, es decir, el tiempo entre solicitudes.

Para entender esto mejor, tomemos un ejemplo concreto de algunas pruebas que ejecuté en un script PHP básico implementado en un servidor apache. El rendimiento máximo obtenido fue de 2011.763 solicitudes / segundo con un tiempo de respuesta promedio de 6.737 ms, un tiempo de reflexión promedio de 0.003 segundos cuando se ejecutan 20 usuarios. La tasa de llegada es la inversa del tiempo entre llegadas, que es la suma del tiempo de respuesta y el tiempo de reflexión. En este caso, X es .2011.763 y λ es 1 / (0.006737 + 0.003). Por lo tanto,

N = X / λ = 2011.763 * 0.009737 = 19.5885

Esto es bastante cercano al número real de usuarios emulados, que es 20.

Estimación de usuarios concurrentes

Todo esto está muy bien, pero ¿cómo nos ayuda esto a estimar el número de usuarios concurrentes reales (con un tiempo de reflexión distinto de cero) que el sistema puede admitir? Utilizando el mismo ejemplo que el anterior, supongamos que si se tratara de una aplicación real, el tiempo promedio entre llegadas es de 5 segundos. Usando la Ley de Little, ahora podemos calcular N como:

N = X / λ = 2011.763 * 5 = 10058 usuarios.

En otras palabras, esta aplicación que se ejecuta en esta misma infraestructura puede admitir más de 10,000 usuarios concurrentes con un tiempo entre llegadas de 5 segundos.

¿Qué dice esto para los tiempos de reflexión? Si suponemos que la aplicación (y la infraestructura) continuarán funcionando de la misma manera a medida que aumenta el número de usuarios conectados (es decir, mantiene el tiempo de respuesta promedio de 0.006737 segundos), el tiempo de reflexión promedio es de 4.993 segundos. Si el tiempo de respuesta se degrada a medida que aumenta la carga (que suele ser el caso después de un cierto punto), la cantidad de usuarios admitidos también disminuirá correspondientemente.

Una aplicación bien diseñada puede escalar linealmente para admitir 10 o 100 de miles de usuarios. En el caso de sitios web grandes como Facebook, Ebay y Flickr, las aplicaciones escalan para manejar a millones de usuarios. Pero obviamente, estas compañías han invertido tremendamente para garantizar que sus aplicaciones y la infraestructura de software puedan escalar.

La Ley de Little se puede usar para estimar el número máximo de usuarios concurrentes que su aplicación puede admitir. Como tal, es una herramienta útil para obtener una idea rápida y aproximada. Por ejemplo, si la Ley de Little indica que la aplicación solo puede admitir 10,000 usuarios pero su objetivo es realmente 20,000 usuarios, usted sabe que tiene trabajo que hacer para mejorar el rendimiento básico.

Me gusta la respuesta de Kirill Zubovsky: “probablemente mucho más de lo que crees que puedes”.

He trabajado en diferentes entornos de alta carga, desde grandes sitios de comercio electrónico hasta sitios pequeños que reciben tráfico masivo después de aparecer en la televisión nacional. La respuesta anterior se ajusta al 98% del tiempo. La mayoría de las aplicaciones web nunca llegan a ser lo suficientemente grandes como para necesitar más que un pequeño servidor web.

El camino correcto, o el camino Try and See

La forma “correcta” implica el uso de una colección de herramientas de prueba de carga para simular diferentes cantidades de tráfico y realmente probar cuánto tráfico pueden manejar varias configuraciones de servidor antes de que se ahoguen.

La forma más barata y fácil se reduce a girar un equilibrador de carga, un servidor de base de datos y más servidores de los que crees que necesitas, y luego reducir las cosas (o subir) hasta que el sitio funcione sin problemas y no estés roto.

Si tiene un negocio sólido, un par de semanas para prepararse, unos pocos miles en efectivo y su propio equipo de desarrollo, la primera forma con las herramientas de prueba de carga podría tener sentido.

Si tiene un inicio inestable y está durmiendo en el sofá de su amigo y comiendo ramen para darle una pista más larga, el enfoque de “obtener algunos servidores y ver” es mucho más apropiado.

Amazon hace que los clústeres de servidores de escalado sean tan rápidos y rentables que, a menos que esté ganando decenas de miles de dólares por hora en su sitio web, hacer que caiga durante 20 minutos mientras activa más servidores tiene mucho más ROI que una prueba de carga significativa esfuerzo.

El número de usuarios que su aplicación puede manejar depende de cuán fuerte sea la API de back-end para su aplicación.

Si está utilizando un servicio como Parse como back-end de su aplicación, le cobrarán por la cantidad de llamadas API y solo tendrá que preocuparse por pagar la factura al final del mes.

Si está utilizando un servidor dedicado, puede poner una carga de alrededor de 200 usuarios simultáneos fácilmente para servidores php y puede duplicar eso para servidores basados ​​en Node.js. es decir, 400 usuarios concurrentes.

Tenga en cuenta que existe una diferencia entre los usuarios concurrentes y el número de usuarios. Una aplicación como una aplicación de chat puede tener muchos usuarios concurrentes al mismo tiempo. sin embargo, una aplicación como “Buscar un médico” puede tener menos usuarios usándola al mismo tiempo.

Puedes usar JMeter para probar los límites de tu API. También hay herramientas de prueba basadas en la nube disponibles como BlazeMeter: The JMeter Cloud Blog: ¿cómo analiza los resultados de una prueba de carga a gran escala? lo que puede facilitarle las pruebas, ya que también le permiten simular usuarios reales mediante el uso de muchos sistemas para acceder a su API. Sin embargo, esto te costará más.

Respuesta corta: probablemente mucho más de lo que crees que puedes.

Respuesta larga: depende mucho de qué tan bien construya su aplicación, en qué idioma / plataforma esté construida y cómo se implemente.

Una aplicación de iOS que vive y funciona en el teléfono del usuario (como mi http://receiptdonkey.com ) no tiene muchas razones para bloquearse, por lo que rara vez lo hace. Pensé en algunos escenarios de bloqueo en mi código y trabajé alrededor de ellos, y la única dependencia que tengo desde fuera de mi propio código es Dropbox, y también han creado su SDK para que sea bastante a prueba de choques.

Si está creando una aplicación Rails, por ejemplo, y no está conectada a ningún servicio de terceros, y su código es bueno, entonces solo se bloqueará si demasiados usuarios vienen a su sitio para usar su aplicación. En ese caso, solo agregue más servidores y su problema se resolverá, la mayoría de las veces.

Es más probable que su aplicación se bloquee si tiene muchas dependencias en forma de bibliotecas y API de terceros porque sería muy difícil de probar e identificar todos los puntos de falla. Puede escribir un gran código la mayor parte del tiempo, pero una de las API puede generar un error incorrecto en algunas solicitudes, y eso es algo que se habría perdido. Ahora, de repente, su aplicación es muy propensa a errores debido a un pequeño problema.

Dicho todo esto, no se preocupe por cuántos usuarios puede recibir hasta que se bloquee. Tantos usuarios que su aplicación se está volviendo bunkers es un buen problema. Cree la aplicación para que funcione bien y si tiene la suerte de que se bloquee debido al tráfico, trabaje en ese problema.

Hola amigo,

No estoy seguro de encontrar esa información de su parte. Pero puede usar el análisis de aplicaciones para encontrar los errores de descarga, las desinstalaciones, la ubicación de las personas, los usuarios, la duración promedio del tiempo, etc.

Depende de las especificaciones del servidor y del servidor.

¿Puede su backend tomar todos los datos entrantes y salientes y en qué cantidad puede manejar? También la estructura del backend como en está usando Parse o Node.js.

¿Qué tan bien está construida su aplicación? ¿Se están creando datos innecesarios?

Busque herramientas de prueba de estrés relacionadas con su industria.