Capacidad y dimensionamiento

A cuántas personas atiende a la vez una instancia de Archestack, qué servidores necesita para ello y cuántos espacios de trabajo admite un servidor de base de datos. Todas las cifras de esta página se midieron en pruebas de carga el 23 de septiembre de 2026, con personas simuladas que iniciaban sesión y trabajaban con la aplicación. Ninguna es una proyección: una instalación más grande se dimensiona en bloques completos de un tamaño probado.

De un vistazo

Todas estas cifras son con las actualizaciones en vivo desactivadas. Con ellas activadas, que es lo predeterminado, un espacio de trabajo funciona con holgura hasta unas 100 personas a la vez.

Cómo funcionan las pruebas

• Personas. Cada persona simulada inicia sesión con su propia cuenta y trabaja con listas, registros, búsquedas, guardados y un panel, con una pausa media de 6 segundos entre clics. Una cuarta parte usa el builder y el resto, la aplicación publicada. "Personas a la vez" cuenta las personas que hacen clic al mismo tiempo, no las cuentas.
• Escalones. Las personas se añaden a lo largo de 45 segundos y después se mantienen durante 3 minutos. Todas las cifras proceden de esos 3 minutos estables.
• Rápido. Un escalón cuenta como rápido cuando el 95 % de las cargas de página terminan en menos de 1 segundo y fallan menos del 1 % de las peticiones. Una carga de página va desde el clic hasta el último dato de la página.
• Máquina. Un PC de escritorio con un Intel Core i9-12900KF y 96 GB de memoria. Cada servidor se ejecutó en un contenedor con núcleos de procesador propios, y el generador de carga también tenía núcleos propios. PostgreSQL 16, PgBouncer 1.25 donde se usó, límites de peticiones activados.

Un espacio de trabajo, muchas personas

Una sola empresa con todo el mundo en el mismo espacio de trabajo, con 2500 clientes, 25 000 pedidos y 75 000 líneas de pedido, en un servidor de aplicaciones de 4 núcleos y un servidor de base de datos de 2 núcleos:

Por encima de 1000 personas el generador de carga se quedó sin procesador, así que no se llegó a encontrar el límite de un espacio de trabajo. Con 1000, ninguno de los dos servidores usaba un núcleo entero.

Actualizaciones en vivo

Por defecto, cada fila guardada se envía a todas las pantallas abiertas que la muestran, y cada una de esas pantallas vuelve a cargar su registro, sus listas relacionadas y sus etiquetas. Ese coste crece con el cuadrado del número de personas de un espacio de trabajo. Con la misma versión y los mismos servidores, unas 100 personas a la vez funcionaban con holgura con las actualizaciones en vivo activadas, frente a 1000 con ellas desactivadas; con 200 personas, el 86 % de todas las peticiones eran esas recargas.

Desactívalas con Realtime__EntityChanges=false en el servidor de aplicaciones. Las pantallas abiertas muestran entonces el cambio de un compañero la próxima vez que se cargan. Guardar, buscar, las notificaciones y ver quién más está en una página funcionan como antes. Todas las demás cifras de esta página son con las actualizaciones en vivo desactivadas.

Muchas empresas en una instancia

Empresas de 100 personas cada una, cada empresa un espacio de trabajo con su propia copia de la aplicación (500 clientes, 5000 pedidos y 15 000 líneas de pedido), en dos tamaños de servidor:

La primera cifra de cada par es el servidor de aplicaciones y la segunda, el servidor de base de datos. Como regla general, 1000 personas a la vez usan aproximadamente medio núcleo de aplicación y medio núcleo de base de datos.

Dónde se queda corto un servidor de base de datos

Con conexión directa, cada espacio de trabajo mantiene sus propios pools de conexiones, y estos crecen con la carga. Con 5000 personas, el servidor de base de datos 4 + 4 llegó a casi 2000 conexiones y las cargas de página se desplomaron; un par 6 + 6 no llegó a estabilizarse nunca. A través de PgBouncer en modo transacción, las bases de datos de los espacios de trabajo comparten pools de unas pocas conexiones cada uno: el par 4 + 4 atendió entonces a 4000 personas con el 95 % de las páginas en menos de 54 ms con 400 conexiones, y un par 8 + 8 sostuvo a 8000 personas con 757. Esa prueba 8 + 8 compartía los núcleos del PC con el generador de carga, así que solo muestra las conexiones y no se usa para dimensionar.

Servidores para más personas

Un bloque es el par probado: un servidor de aplicaciones de 4 núcleos y un servidor de base de datos de 4 núcleos con PgBouncer, contado para 4000 personas para que le quede algo de margen. Una instalación más grande añade bloques completos.

Hoy cada bloque es un despliegue propio, y una empresa vive en un solo bloque. Repartir empresas entre varios bloques detrás de una sola dirección y un solo inicio de sesión todavía no está desarrollado.

Muchos espacios de trabajo en un servidor de base de datos

Una prueba aparte fue añadiendo espacios de trabajo a un servidor de base de datos, con 50 de ellos en uso en todo momento, hasta llegar a 5000 espacios de trabajo:

• Sin fallos. 5000 espacios de trabajo sin que fallara ni un alta ni una petición.
• Sin uso, no cuesta nada. Un espacio de trabajo que nadie usa no mantiene ninguna conexión a la base de datos. Tras seis minutos sin uso, los 5000 mantenían 3 conexiones entre todos.
• Un espacio de trabajo nuevo en aproximadamente un segundo. 0,9 segundos de mediana, con las dos bases de datos creadas y preparadas.
• Unos 18 MB de disco por espacio de trabajo: dos bases de datos y una aplicación pequeña, antes de tus propios datos.

El número de conexiones mantenidas no varía por muchos espacios de trabajo que haya, porque solo mantienen alguna los que están en uso. Dos cosas sí crecen con el número de espacios de trabajo: la memoria del servidor de aplicaciones y el tiempo que tarda un reinicio hasta que la API vuelve a responder, que llegó a casi cuatro minutos con 5000 espacios de trabajo. Planifica en consecuencia los reinicios de una instancia grande.

Los ajustes detrás de estas cifras

• Actualizaciones en vivo desactivadas: Realtime__EntityChanges=false en el servidor de aplicaciones, ver más arriba.
• Memoria compartida de la base de datos: shm_size: 1g en el contenedor de PostgreSQL. PostgreSQL guarda estadísticas de cada base de datos en memoria compartida, unos 55 KB por cada una, y Docker da a un contenedor 64 MB salvo que se le indique otra cosa. 1 GB alcanza para unos 9000 espacios de trabajo.
• Pool de conexiones: PgBouncer en modo transacción, con una entrada de base de datos comodín para que un espacio de trabajo nuevo no necesite configuración, 2 conexiones por base de datos con 1 de reserva, y un techo de conexiones al servidor de al menos 4 por empresa activa y por debajo del max_connections de PostgreSQL. Un techo más ajustado hace que PgBouncer cierre las conexiones de una empresa para abrir las de otra: 400 conexiones para 150 empresas saturaron ambos servidores con esa rotación. Las cadenas de conexión del servidor de aplicaciones llevan No Reset On Close=true. La sincronización de datos con otros sistemas usa tablas temporales, que el pooling en modo transacción no conserva, así que sigue necesitando una conexión directa.
• Mantenimiento de la base de datos: con miles de bases de datos, un autovacuum_naptime más largo espacia las visitas que el propio PostgreSQL hace a cada base de datos.

Lo que las cifras no cubren

• Procesadores en la nube. Un procesador virtual en la nube suele ser más lento que un núcleo de este procesador de escritorio.
• La red y el navegador. Los tiempos de página no incluyen la red entre los servidores y tus usuarios, ni el tiempo que tarda el navegador en dibujar la página.
• Aplicaciones más pesadas. Las páginas con más listas relacionadas, o con tablas más grandes, cuestan más por página que las de la aplicación de prueba.
• Más allá de 10 000 personas. Aquí no se extrapola nada más allá de un tamaño probado.

Hacia dónde va esto a continuación

Espacios de trabajo y alojamiento explica la elección entre un espacio de trabajo por instancia y varios, y las dos formas de ejecutar los contenedores.