Capacidade e dimensionamento

Quantas pessoas uma instância do Archestack serve em simultâneo, de que servidores precisa para isso e quantos espaços de trabalho cabem num servidor de base de dados. Todos os valores desta página foram medidos em testes de carga a 23 de setembro de 2026, com pessoas simuladas que iniciam sessão e trabalham na aplicação. Nada disto é uma projeção: uma instalação maior é dimensionada em blocos inteiros de um tamanho testado.

Em resumo

Todos estes valores são com as atualizações em tempo real desligadas. Com elas ligadas, que é a predefinição, um espaço de trabalho funciona com folga até cerca de 100 pessoas em simultâneo.

Como funcionam os testes

• Pessoas. Cada pessoa simulada inicia sessão com a sua própria conta e percorre listas, registos, pesquisas, gravações e um dashboard, com uma pausa média de 6 segundos entre cliques. Um quarto delas usa o builder, as restantes a aplicação publicada. "Pessoas em simultâneo" conta as pessoas que clicam ao mesmo tempo, não as contas.
• Patamares. As pessoas são adicionadas ao longo de 45 segundos e depois mantidas durante 3 minutos. Todos os valores vêm desses 3 minutos estáveis.
• Rápido. Um patamar conta como rápido quando 95% dos carregamentos de página terminam em 1 segundo ou menos e menos de 1% dos pedidos falham. Um carregamento de página vai do clique até ao último dado da página.
• Máquina. Um PC de secretária com um Intel Core i9-12900KF e 96 GB de memória. Cada servidor correu num container com núcleos de processador próprios, e o gerador de carga também tinha núcleos próprios. PostgreSQL 16, PgBouncer 1.25 onde foi usado, limites de pedidos ativos.

Um espaço de trabalho, muitas pessoas

Uma empresa com toda a gente no mesmo espaço de trabalho, com 2500 clientes, 25 000 encomendas e 75 000 linhas de encomenda, num servidor de aplicação de 4 núcleos e num servidor de base de dados de 2 núcleos:

Acima de 1000 pessoas, o gerador de carga ficou sem processador, por isso o limite de um espaço de trabalho não foi encontrado. Com 1000, nenhum dos servidores usava um núcleo inteiro.

Atualizações em tempo real

Por predefinição, cada linha guardada é enviada para todos os ecrãs abertos que a mostram, e cada um desses ecrãs recarrega o seu registo, as suas listas relacionadas e as respetivas etiquetas. Esse custo cresce com o quadrado do número de pessoas num espaço de trabalho. Com a mesma versão e os mesmos servidores, cerca de 100 pessoas em simultâneo funcionavam com folga com as atualizações em tempo real ligadas, contra 1000 com elas desligadas; com 200 pessoas, 86% de todos os pedidos eram esses recarregamentos.

Desligue-as com Realtime__EntityChanges=false no servidor de aplicação. Os ecrãs abertos mostram então a alteração de um colega da próxima vez que carregam. Guardar, pesquisar, as notificações e ver quem mais está numa página funcionam como antes. Todos os outros valores desta página são com as atualizações em tempo real desligadas.

Muitas empresas numa instância

Empresas de 100 pessoas cada, cada empresa um espaço de trabalho com a sua própria cópia da aplicação (500 clientes, 5000 encomendas e 15 000 linhas de encomenda), em dois tamanhos de servidor:

O primeiro valor de cada par é o servidor de aplicação, o segundo o servidor de base de dados. Como regra geral, 1000 pessoas em simultâneo usam cerca de meio núcleo de aplicação e meio núcleo de base de dados.

Onde um servidor de base de dados chega ao limite

Com ligação direta, cada espaço de trabalho mantém pools de ligações próprios, que crescem com a carga. Com 5000 pessoas, o servidor de base de dados 4 + 4 chegou a quase 2000 ligações e os carregamentos de página colapsaram; um par 6 + 6 nunca chegou a estabilizar. Através do PgBouncer em modo de transação, as bases de dados dos espaços de trabalho partilham pools de poucas ligações cada: o par 4 + 4 serviu então 4000 pessoas com 95% das páginas em 54 ms ou menos, com 400 ligações, e um par 8 + 8 aguentou 8000 pessoas com 757. Essa execução 8 + 8 partilhou os núcleos do PC com o gerador de carga, por isso só mostra as ligações e não é usada para dimensionamento.

Servidores para mais pessoas

Um bloco é o par testado: um servidor de aplicação de 4 núcleos e um servidor de base de dados de 4 núcleos com PgBouncer, contado para 4000 pessoas para manter alguma margem. Uma instalação maior acrescenta blocos inteiros.

Hoje, cada bloco é uma instalação própria, e uma empresa vive num só bloco. Repartir empresas por vários blocos atrás de um só endereço e de um só início de sessão ainda não está construído.

Muitos espaços de trabalho num servidor de base de dados

Um teste separado foi acrescentando espaços de trabalho a um servidor de base de dados, com 50 deles em uso a cada momento, até 5000 espaços de trabalho:

• Sem falhas. 5000 espaços de trabalho sem nenhuma inscrição falhada nem nenhum pedido falhado.
• Inativo não custa nada. Um espaço de trabalho que ninguém usa não mantém nenhuma ligação à base de dados. Após seis minutos sem uso, os 5000 mantinham 3 ligações entre todos.
• Um novo espaço de trabalho em cerca de um segundo. 0,9 segundos de mediana, com as duas bases de dados criadas e preparadas.
• Cerca de 18 MB de disco por espaço de trabalho: duas bases de dados e uma pequena aplicação, antes dos seus próprios dados.

As ligações mantidas ficam estáveis seja qual for o número de espaços de trabalho, porque só os que estão em uso mantêm alguma. Há duas coisas que crescem com o número de espaços de trabalho: a memória do servidor de aplicação e o tempo que um reinício leva até a API voltar a responder, que chegou a quase quatro minutos com 5000 espaços de trabalho. Planeie os reinícios de uma instância grande em conformidade.

Definições por trás destes números

• Atualizações em tempo real desligadas: Realtime__EntityChanges=false no servidor de aplicação, ver acima.
• Memória partilhada da base de dados: shm_size: 1g no container do PostgreSQL. O PostgreSQL guarda estatísticas de cada base de dados em memória partilhada, cerca de 55 KB cada, e o Docker dá a um container 64 MB, salvo indicação em contrário. 1 GB chega para uns 9000 espaços de trabalho.
• Pooling de ligações: PgBouncer em modo de transação, com uma entrada de base de dados wildcard para que um novo espaço de trabalho não precise de configuração, 2 ligações por base de dados com 1 de reserva, e um teto de ligações ao servidor de pelo menos 4 por empresa ativa e abaixo do max_connections do PostgreSQL. Um teto mais apertado faz o PgBouncer fechar as ligações de uma empresa para abrir as de outra: 400 ligações para 150 empresas saturaram os dois servidores com essa rotação. As connection strings do servidor de aplicação levam No Reset On Close=true. A sincronização de dados com outros sistemas usa tabelas temporárias, que o pooling por transação não mantém, por isso continua a precisar de uma ligação direta.
• Manutenção da base de dados: com milhares de bases de dados, um autovacuum_naptime mais longo espaça as visitas do próprio PostgreSQL a cada base de dados.

O que os números não cobrem

• Processadores na cloud. Um processador virtual na cloud é normalmente mais lento do que um núcleo deste processador de secretária.
• A rede e o browser. Os tempos de página excluem a rede entre os servidores e os seus utilizadores, e o tempo que o browser leva a desenhar a página.
• Aplicações mais pesadas. Páginas com mais listas relacionadas, ou tabelas maiores, custam mais por página do que as da aplicação de teste.
• Acima de 10 000 pessoas. Nada aqui é extrapolado para lá de um tamanho testado.

Para onde seguir a partir daqui

Espaços de trabalho e alojamento explica a escolha entre um espaço de trabalho por instância e vários, e as duas formas de correr os containers.