¿Es nginx/node.js/postgres una arquitectura muy escalable?

Question

Tengo una aplicación que se ejecuta con:

• una instancia de nginx como el frontend (que sirve archivo estático)
• un grupo de aplicación node.js para el backend (usando clúster y expressjs módulos)
• una instancia de Postgres como el DB

¿es esta arquitectura suficiente si la aplicación necesita escalabilidad (esto es sólo para las solicitudes HTTP/REST) ​​para:

solicitud

• 500 por segundo (cada uno solicitudes sólo recupera los datos de la base de datos, los datos podrían ser varias ko, y sin grandes cálculos necesarios después de la zona de alcance).

• 20.000 usuarios conectados a la vez

Dónde podrían ser los cuellos de botella?

Answer 1

Para la carga especificada (500 solicitudes simples/segundo), no hubiera pensado que esto sería un problema. Y creo que un clúster de instancias de nodo ni siquiera será necesario.

Sin embargo, como solo tiene una sola instancia, cuando se trata de escalar, es muy probable que sea su cuello de botella. También tienes el problema adicional de que este sería tu único punto de falla (no estoy familiarizado con Postgres, aquí trabajé con un cluster y dataguard de Oracle lo que significa que tenemos un clúster de base de datos de respaldo para mitigar eso) .

Si no necesita un modelo de datos relacionales, entonces algo de MongoDB puede ser una opción más escalable.

Otra cosa a tener en cuenta es su infraestructura de red. Si va a agregar clusters/nodes, asegúrese de que la red pueda manejar la carga distribuida.

Una última cosa: en general, es imposible determinar si una aplicación en una arquitectura puede manejar una carga en particular sin pruebas de rendimiento/volumen/estrés, por lo que la respuesta es "tal vez".

Answer 2

Debería estar bien a 500 operaciones/seg. Rediseñe si espera ingresar a las mil operaciones/seg.

Sin saber muchos más datos de usted, la E/S de disco será su cuello de botella más probable. Esto ocurrirá en su base de datos PostgreSQL a aproximadamente 10k ops/sec si está haciendo I/O'ing desde el disco duro en el hardware estándar y también se ralentiza si está haciendo un JOIN en el comando SQL. Esto también ralentizará a los usuarios más concurrentes que haya intentado acceder a una sola unidad. El tiempo de búsqueda de la unidad se volverá loco, ya que constantemente accederá aleatoriamente a la unidad.

Debe investigar la estructura de sus datos y si se necesita una base de datos relacional (¿tiene que hacer un JOIN?). Una solución noSQL podría ser el camino a seguir. Siempre intente hacer que su E/S de disco sea lo más distribuida y secuencial posible.