Le recomendaría que haga algunas pruebas de carga en un entorno de control de calidad con infraestructura similar para tener una idea de la cantidad de carga que los usuarios concurrentes que realizan transacciones clave colocarán en el sistema. Una transacción podría ser leer una publicación, escribir una publicación, realizar una búsqueda, etc. Es posible que ciertas transacciones consuman más recursos que otras (búsquedas y escrituras) y que desee dividir estos componentes en máquinas separadas y dedicadas para mantener las operaciones de lectura fluyendo sin problemas.
Debería poder realizar hits de tamaño similar para cada tipo de transacción para comprender cómo se desempeñan entre sí, pero no olvide hacer una prueba mixta ya que ciertas operaciones pueden bloquear otras operaciones y querrá ver qué sucede allí .
Por lo tanto, puede comenzar con 100, luego 200, luego 300, luego 400, hasta X transacciones de lectura simultáneas en un ciclo durante algún intervalo, y tomar algunas medidas de carga durante esos intervalos. Entonces escribe. Entonces haz búsquedas. Compare las mediciones para determinar qué operaciones tienen la carga más alta y cómo se ve su curva de crecimiento durante esos intervalos (lineal, exponencial, logarítmico, etc.) que lo ayudarán a proyectar la carga en ciertos umbrales concurrentes.
- Dado el panorama de datos de Big Data Analytics, productos SaaS, IoT, ¿qué área es un paso más natural para CTO? ¿Desarrollo o arquitecto?
- ¿SaaS con ciertos elementos virales, mejor lanzamiento como freemium o una prueba gratuita?
- ¿Cuál sería la arquitectura y el diseño correctos para un proyecto que utiliza openCV y Python?
- Como proveedor de SaaS, ¿cuál es la forma más efectiva de pedir a los clientes que realicen revisiones?
- ¿Cuáles son buenas alternativas para Zenefits?
Luego haga algo como 33% de lectura, 33% de escritura, 33% de búsqueda simultánea y vea cómo se desarrollan todas las operaciones juntas y si tiene algún problema de bloqueo. (De nuevo, en incrementos).
Luego, finalmente, querrá ajustar lo que cree que podría ser el volumen normal (80% de lectura, 10% de escritura, 10% de búsqueda o algo así). (De nuevo, en incrementos).
Una vez que haya hecho eso, empuje la máquina al fracaso utilizando el modelo de “volumen normal anticipado” para comprender cuál es su umbral superior.
Ahora, dése espacio libre en esa máquina. Digamos que vomitó a 1,000 concurrentes. Tal vez diremos que 800 operaciones concurrentes es lo máximo que queremos poner en una sola máquina debido a esto. Esta es una decisión, pero concédete suficiente espacio sin darte demasiado espacio como para estar subutilizando completamente la caja.
Bien, ahora sabemos que cada máquina puede hacer X concurrentes.
En función de cada usuario, en nuestro ejemplo de 800 concurrentes por servidor, usted tomaría el precio de ese servidor dividido por 800 (ya que cada concurrente es un usuario), y ese es el costo por usuario para esa máquina. Esto supone una utilización del 100%, por lo que siempre habrá un servidor para un usuario si tiene 800 usuarios. Si escatima y mide con una utilización del 50%, podría ser enclavado en las horas pico y no poder atender las solicitudes.
Por lo tanto, tendrá que preocuparse por el aspecto que tendrá su uso pico y no pico. Habrá horas pico y no pico. Mi consejo: planifique las horas pico cuando planifique la capacidad (es decir, si su pico es de 1600 concurrentes, necesitará al menos dos máquinas para manejarlo, incluso si solo promedia 800 concurrentes durante las horas no pico).
En este punto, descubrir estos números será en su mayoría un trabajo de conjetura educado hasta que pueda obtener datos reales en vivo.
Después de llegar a un pico estimado, observe sus medidas y descubra dónde se encuentra. ¿Necesita un servidor, dos servidores, etc. para manejar esa carga?
Es realmente un juego de tuning.
Solo un aviso: si cambia su base de código, es posible que sus mediciones ya no sean válidas, ya que las mediciones se tomaron contra lo que ahora es una versión anterior del sitio.
Las pruebas de carga pueden darle una idea, pero querrá ver esos números una vez que entre en funcionamiento. Es posible que conozca sus números de capacidad, pero no puede predecir cuántas personas se presentarán realmente a la fiesta.
No olvide especificar el almacenamiento por usuario en sus estimaciones.
Hay un montón de herramientas de prueba de carga de FOSS por ahí que debe considerar para comenzar. Jmeter es bastante popular con el que podrías comenzar.
Un último consejo: busque en las opciones de nube disponibles que le permiten ampliar / reducir según demanda. Algunos proveedores de la nube tienen API donde puede monitorear mediante programación la carga y aumentar o disminuir las instancias según sea necesario. De esa manera, sabrá cuánto le costará por usuario, pero en realidad no necesita mantener esos servidores adicionales durante las horas pico; puedes girar una instancia cuando llegue el momento.
La mejor de las suertes.
Mis dos centavos.. 