Low Code Web
27 min
Data: de publicação: 30/09/2026
Esta versão do Low Code Web corrige o travamento das execuções de FaaS das versões 1.18.1 a 1.18.3: os clientes HTTP compartilhados passam a ter limites de conexão e timeouts, com padrões calibrados e configuráveis por variáveis de ambiente. Nenhuma configuração é obrigatória, e voltar para a 1.18.3 traz o travamento de volta. Recomenda-se, porém, revisar heap, threads e cabeçalho HTTP dos pods: o risco de falta de memória dessa combinação existe desde a 0.7.4 e não muda nesta versão.
🚀 Execuções de FaaS presas em fila após a versão 1.18.1
O que foi corrigido
- Limites de conexão nos dois clientes: 50 por destino e 200 no total.
- Timeouts para conectar, aguardar conexão livre e receber resposta, com padrões por cliente (mais curtos no genérico); ao estourar, a chamada falha e libera a conexão.
- Reutilização de conexões ociosas limitada a 2 s: o node-faas as fecha após 5 s, e reaproveitar uma conexão nesse instante fazia a execução falhar, sem repetição automática; o limite deixa 3 s de margem (KEEPALIVEMS em Parâmetros).
- Variáveis de ambiente com padrões (Configuração); nenhuma ação obrigatória.
- Log dos valores em uso na primeira utilização de cada cliente, com WARN para valor inválido ajustado ou proteção desligada (ex.: timeout 0).
- Substituição de FAASCLIENT_DEFAULTCONNECTION_CONNECTIONTIMEOUT (propriedade faas-client.default-connection.connection-timeout): só valeu da 1.6.0 à 1.8.6 (antes, aceita mas não lida; valor único em segundos, 90 se ausente, para os três timeouts); desde a 1.8.7 não é lida, e o FaaS ficou sem timeout. Substituída pelos FAASCLIENT_HTTP_* (os 90 s de resposta equivalem ao padrão antigo); continua ignorada e pode ser removida.
- Testes automatizados do limite antigo, da concorrência, da liberação por timeout, da reutilização de conexões e da leitura das variáveis.
Configuração
Os padrões já resolvem o travamento. Os parâmetros são variáveis de ambiente no ConfigMap do deployment do Low Code. Cada execução ocupa uma thread do Low Code durante todo o percurso: obtém conexão do pool (até MAXCONNPERROUTE; com todas ocupadas, espera na fila até CONNECTIONREQUESTTIMEOUTMS), conecta se precisar (até CONNECTTIMEOUTMS), aguarda a resposta (até READTIMEOUTMS) e devolve a conexão (descartada se ociosa além de KEEPALIVEMS). Quem espera na fila também ocupa thread (as mesmas de telas, APIs e health checks).
Parâmetros
Dois grupos com os mesmos seis parâmetros; nome = prefixo + parâmetro.
- FAASCLIENT_HTTP_*: chamadas ao node-faas (grupo deste card).
- APP_HTTPCLIENT_*: busca de tokens no Keycloak (recurso público com credenciais do projeto ou padrão; agente iniciado sem usuário autenticado). Raramente precisa de ajuste.
- Grafia sem separador: FAASCLIENT_HTTP_MAX_CONN_PER_ROUTE não é reconhecida, e o padrão vale sem aviso (mesma convenção de FAASCLIENT_DEFAULTCONNECTION_URL).
MAXCONNPERROUTE— padrão 50 nos dois grupos
- Máximo de execuções de FaaS simultâneas por pod; com 3 réplicas, até 150 no node-faas (mais os pods extras do rolling update). Ao atingir, não falha: entra na fila.
- No máximo cerca de metade de SERVER_TOMCAT_THREADS_MAX e nunca acima de 100 (150 rejeitado; fórmula 1): funções que chamam o Low Code precisam de uma segunda thread e, sem ela, só terminam por timeout.
- Aumentar só com execuções legítimas acima do limite e folga no node-faas (senão a fila só muda de lugar); diminuir para protegê-lo de picos.
MAXCONNTOTAL — padrão 200 nos dois grupos
- Teto somando destinos (só importa com vários, ex.: FaaS por tenant). Ao atingir, não falha: entra na fila. Deve ser ≥ MAXCONNPERROUTE, senão vira o limite (o log avisa). Não dividir pelas réplicas.
CONNECTTIMEOUTMS — padrão 5000 nos dois grupos
- Abertura TCP de conexão nova (no genérico, também cada etapa do TLS). Ao estourar: connect timed out (destino fora do ar, sobrecarregado ou rede); aumentar não resolve.
CONNECTIONREQUESTTIMEOUTMS — padrão 10000 no FaaS, 5000 no genérico
- Espera na fila por conexão livre. Ao estourar: Timeout waiting for connection from pool.
- Faixa válida (fórmula 7): 10000 ≤ FAASCLIENT_HTTP_CONNECTIONREQUESTTIMEOUTMS < 15000 e abaixo do pool.connectionTimeout de cada tenant (11 a 14 s não testados).
- Abaixo de 10 s, perde execuções mesmo com carga saudável. Esperas longas prendem threads (≈ execuções/s × espera: com 30 s, cerca de 7 execuções/s por pod ocupam 200 threads; com 10 s, cerca de 20) e, como cada execução na fila segura uma conexão do pool de banco (inferência), passar de APP_DATASOURCE_POOL_CONNECTIONTIMEOUT (padrão 15000) ou do pool.connectionTimeout do tenant gera erros de banco e de autenticação enganosos (até 352 403 Access Denied numa rodada com 20 s).
- Aumentar, dentro da faixa, só para picos curtos acima da capacidade do node-faas; para preservar threads, use réplicas ou revise threads e cabeçalho.
READTIMEOUTMS — padrão 90000 no FaaS, 10000 no genérico
- Tempo máximo sem resposta (reinicia a cada trecho recebido). Ao estourar: Read timed out, conexão descartada e vaga liberada; é o que impede uma chamada presa de ocupar a vaga para sempre.
- Não limita a função: ela segue no node-faas com todos os efeitos (gravações, integrações); nova tentativa do usuário pode executá-la de novo.
- script.timeout do node-faas (padrão 60 s): no runtime 1.x (produção) só cobre o código até a primeira espera assíncrona (await de HTTP, banco, SDK ou setTimeout), e READTIMEOUTMS é o único limite efetivo; no 2.x, interrompe a função cerca de 61 s após o início da execução (a fila interna não conta).
- Aumentar para funções legitimamente longas (relatórios, integrações lentas, lote), junto com o script.timeout e o timeout do ingress.
KEEPALIVEMS — padrão 2000 nos dois grupos
- Tempo máximo de reaproveitamento de uma conexão ociosa; depois, abre-se outra (milissegundos no cluster).
- Deve ficar bem abaixo dos 5 s do node-faas (com Node.js 20, das imagens atuais, o fechamento ocorre exatamente no tempo anunciado); a margem de 3 s também absorve pausas do runtime 1.x (função síncrona longa impede a leitura das conexões). Ao errar: falhas esporádicas (tráfego baixo ou rajadas) com Connection reset ou <host>:<porta> failed to respond (NoHttpResponseException; ex.: node-faas:3000 failed to respond).
- 0 desliga o limite (vale só o Keep-Alive do servidor): não recomendado no FaaS; gera WARN, assim como valor não abaixo de 5 s.
- Melhoria recomendada no node-faas, fora desta versão: server.keepAliveTimeout (hoje 5 s) bem acima deste limite elimina o risco.
Timeouts 0 ou negativos = sem limite, como nas versões que travavam. Não recomendado; gera WARN.
Exemplo de ConfigMap
data:
FAASCLIENT_HTTP_MAXCONNPERROUTE: '50'
FAASCLIENT_HTTP_MAXCONNTOTAL: '200'
FAASCLIENT_HTTP_CONNECTTIMEOUTMS: '5000'
FAASCLIENT_HTTP_CONNECTIONREQUESTTIMEOUTMS: '10000'
FAASCLIENT_HTTP_READTIMEOUTMS: '90000'
FAASCLIENT_HTTP_KEEPALIVEMS: '2000'
APP_HTTPCLIENT_MAXCONNPERROUTE: '50'
APP_HTTPCLIENT_MAXCONNTOTAL: '200'
APP_HTTPCLIENT_CONNECTTIMEOUTMS: '5000'
APP_HTTPCLIENT_CONNECTIONREQUESTTIMEOUTMS: '5000'
APP_HTTPCLIENT_READTIMEOUTMS: '10000'
APP_HTTPCLIENT_KEEPALIVEMS: '2000'
- Valores entre aspas; declare só o que diferir do padrão (o exemplo equivale a não declarar nada).
- Lidas só na subida do pod: alterações exigem novo rollout (kubectl rollout restart deployment/<nome-do-deployment>).
- Valor não numérico (ex.: 5s) impede a subida: APPLICATION FAILED TO START com a propriedade e a variável (ex.: Property: faas-client.http.read-timeout-ms e Origin: System Environment Property, seguido de "FAASCLIENT_HTTP_READTIMEOUTMS"), código 1 e CrashLoopBackOff (num rollout, os pods antigos seguem atendendo e o rollout para). Veja com kubectl logs <pod> --previous.
Como verificar os valores em uso
Cada pod registra os valores efetivos uma vez: na primeira execução de FaaS e na primeira busca de token.
FaaS HTTP client: maxConnPerRoute=50, maxConnTotal=200, connectTimeoutMs=5000, connectionRequestTimeoutMs=10000, readTimeoutMs=90000, keepAliveMs=2000
REST HTTP client: maxConnPerRoute=50, maxConnTotal=200, connectTimeoutMs=5000, connectionRequestTimeoutMs=5000, readTimeoutMs=10000, keepAliveMs=2000kubectl logs -l app=<nome-do-deployment> --prefix --tail=-1 | grep "HTTP client"- Sem a linha: o pod ainda não executou FaaS ou não buscou token (casos em Parâmetros). Não é erro.
- --tail=-1 é necessário (com -l, saem só 10 linhas por pod). Com outro rótulo, use kubectl get pods e kubectl logs <nome-do-pod> | grep "HTTP client"; após rotação, a ferramenta de logs centralizada.
- Valor inválido (ex.: MAXCONNPERROUTE igual a 0) aparece já ajustado, seguido de WARN. Valores inesperados: confira a grafia (Parâmetros) e se o pod reiniciou após a alteração.
Como ajustar
- Timeout waiting for connection from pool (cliente recebe 409): fila do pool acima de CONNECTIONREQUESTTIMEOUTMS; deve ser rara no pico. node-faas saturado → réplicas dele. Com folga nele: falhas recorrentes → réplicas do Low Code, ou FAASCLIENT_HTTP_MAXCONNPERROUTE (MPR) até 100 se a fórmula 1 pedir (e até metade das threads); picos curtos → espera maior, abaixo de 15000 e do pool.connectionTimeout dos tenants.
- Read timed out (409): node-faas sem responder por READTIMEOUTMS. Função legitimamente longa → FAASCLIENT_HTTP_READTIMEOUTMS maior (e script.timeout) e, se acionada pelo navegador, a cadeia de entrada (Timeouts da cadeia de entrada); a função continua no node-faas. Sob carga → node-faas saturado, MPR acima da capacidade dele ou falta de threads para as chamadas de volta (fórmula 2).
- connect timed out: o node-faas não aceitou a conexão (pod caído ainda nos endpoints, rede ou NetworkPolicy descartando pacotes, sobrecarga); DNS falha como UnknownHostException, Service sem pods prontos como Connection refused. Investigue pods, Service e endpoints; aumentar o timeout só mascara.
- Connection reset ou failed to respond esporádicos: conexão reaproveitada já fechada (com o padrão, provável pausa longa do node-faas por código síncrono). Confirme KEEPALIVEMS bem abaixo de 5 s e diferente de 0; se persistir, FAASCLIENT_HTTP_KEEPALIVEMS=1000 (conexão nova custa menos de 1 ms) e identifique as funções síncronas longas. Definitivo: server.keepAliveTimeout maior no node-faas.
- Pod sem responder (nem aos health checks) numa lentidão do node-faas, ou health check lento com falhas por fila (e Read timed out, quando há poucas threads): faltam threads (fórmula 2). MPR até metade das threads, espera na faixa da fórmula 7, Health checks e revisão de threads, cabeçalho e heap.
- Unable to acquire JDBC Connection ou Connection is not available, request timed out after ...ms: pool de banco do tenant esgotado; reduza C_pod com réplicas e confira o pool (fórmula 5). Rajadas de 401 ou 403 Access Denied junto: efeito sobre a autenticação, não permissão (inferência).
- Erros encadeados BusinessObject -> BusinessObject -> ... nas chamadas das funções ao Low Code: nos testes, só com falta de memória ou pool de banco esgotado.
- Request header is too large (cliente recebe 400): requisição acima de SERVER_MAXHTTPHEADERSIZE; só a primeira ocorrência em INFO, as seguintes em DEBUG. HeadersTooLargeException em ERROR (cliente recebe 500): cabeçalho de resposta acima do limite.
- Falha ao obter token com os erros acima: mesmas causas no cliente genérico, ou provedor de identidade acima de APP_HTTPCLIENT_READTIMEOUTMS. Verifique o provedor; se for legitimamente lento, aumente APP_HTTPCLIENT_READTIMEOUTMS (ex.: 15000).
Timeouts da cadeia de entrada
Para funções acionadas pelo navegador vale o menor timeout da cadeia (balanceador, roteador, ingress); se um componente desistir antes, o navegador recebe 504 Gateway Timeout e a execução continua no servidor. Tempo máximo no Low Code, com os padrões:
- fila (10 s) + conexão (5 s, só se nova) + resposta (90 s): até cerca de 105 s; com busca de token antes (recursos públicos com credenciais do projeto: 5 + 5 + 10 s), até cerca de 125 s;
- função que chama outra pelo Low Code: cada nível soma nova fila e nova execução;
- sob sobrecarga, as esperas do pool de banco somam até mais 2 × 15 s (medido: 90,4 s com FAASCLIENT_HTTP_MAXCONNPERROUTE 50, 119,5 s com 100 e 132 s com 150); os 130000 do exemplo do Kong ficam no limite.
Confira o componente à frente do Low Code em cada ambiente:
- Kong (ingress do repositório): padrão 60 s; konghq.com/read-timeout e konghq.com/write-timeout no Service (ms). Anotações do ingress-nginx não têm efeito no Kong.
- OpenShift Route: padrão 30 s; haproxy.router.openshift.io/timeout (ex.: 130s). Na AWS, a ociosidade do balanceador também precisa acompanhar.
- ingress-nginx: padrão 60 s; nginx.ingress.kubernetes.io/proxy-read-timeout e nginx.ingress.kubernetes.io/proxy-send-timeout (segundos).
Exemplo para o Kong, no Service do Low Code, acomodando os padrões (até cerca de 125 s; sob sobrecarga, fica no limite):
metadata:
annotations:
konghq.com/read-timeout: "130000"
konghq.com/write-timeout: "130000"Se as funções acionadas pelo navegador forem sempre rápidas, não é preciso alterar.
Health checks
Os probes (/lowcode/management/health/liveness e /readiness) usam as mesmas threads de telas, APIs e FaaS; uma lentidão do node-faas pode atrasá-los e reiniciar vários pods juntos.
- Liveness com timeoutSeconds: 5 e failureThreshold: 3, nunca failureThreshold: 1 (o template de referência usa 1, com 1 s). Mesmo assim, um colapso prolongado reinicia os pods.
- Opcional: porta própria com MANAGEMENT_SERVER_PORT (ex.: 9090). Porta e caminho mudam juntos: probes (liveness, readiness e startup, se houver) em 9090 com /management/health/liveness e /management/health/readiness, sem /lowcode; mudar só um faz os probes falharem. Declarar a porta em ports é recomendado (obrigatório só se o probe usar o nome dela). Com porta separada, o readiness deixa de refletir a saturação das threads principais.
Ajuste de heap, threads e cabeçalho (todos os ambientes)
Esta versão não altera o heap, SERVER_MAXHTTPHEADERSIZE (10MB) nem SERVER_TOMCAT_THREADS_MAX (200); o cabeçalho de 10MB e as 200 threads valem desde a 0.7.4 (2022). Com heap de 4 GB, essa configuração ficou sem memória com cerca de 180 requisições simultâneas por pod, qualquer que fosse MAXCONNPERROUTE (25, 50, 100) ou CONNECTIONREQUESTTIMEOUTMS (5, 10, 20, 30 s). O risco não foi introduzido pela 1.18.4; voltar para a 1.18.3 não o elimina e traz de volta o travamento. Revise esta seção em todos os ambientes. Os limites valem por pod; o total no node-faas e no PostgreSQL é o limite × réplicas. Nesta seção, MPR = FAASCLIENT_HTTP_MAXCONNPERROUTE, T = SERVER_TOMCAT_THREADS_MAX e H = SERVER_MAXHTTPHEADERSIZE.
Parametrização por faixa de heap
- Heap efetivo: -Xmx, ou limite do container × MaxRAMPercentage (70% de 4Gi ≈ 2,8 GiB); sem nenhum dos dois, 25% do limite (1 GiB com 4Gi). Entre faixas, use a inferior ou a fórmula 3.
- Uso intenso: X_pod acima de 40, falhas por fila recorrentes em pico normal, ou C_pod acima do que o uso normal da faixa comporta.
- Tetos com 10MB (130, 200, 270) supõem base até 0,4 GB e nenhuma conexão longa; senão, fórmula 3 ou 64KB. Nos limites com − O, substitua O; os vindos só da fórmula 5 (180 − K, 130, 80) ainda não descontam os demais usos do banco.
- Demais parâmetros e pool de banco: padrões. Números medidos, emulados (4 GB com cabeçalho de 7400KB para 6 GB e 5120KB para 8 GB) ou calculados, num ambiente local (Validação): dimensione pelas fórmulas.
Abaixo de 4 GB (inclui o template de referência: limite de 4Gi, MaxRAMPercentage=70)
- Distribuída: falta memória a partir de cerca de 115 a 120 simultâneas (calculado). Use a recomendação de 4 GB com 64KB.
- Sem 64KB: aumente o limite do container até a faixa de 4 GB (cerca de 5,7Gi) e aplique 130 threads com mais réplicas; só aumentar o heap não basta. Mantendo cerca de 2,8 GiB e 10MB, a fórmula 3 dá cerca de 85 threads: cerca de 15 execuções simultâneas (85 − 50 − 20) menos O, e o MPR 50 passa de T ÷ 2 (cerca de 42). Não recomendado.
Heap de 4 GB
- Distribuída: não é segura. cerca de 130 requisições em processamento com folga de 15%, falta de memória acima de cerca de 170 (calculado) e OutOfMemoryError com 180 em todas as configurações testadas (com node-faas lento, entre 120 e 220), de qualquer tipo de requisição. Após o erro, a JVM não encerra e fica degradada (50% a 79% do tempo em coleta); não foi testado se o liveness reinicia o pod nesse estado.
- Uso normal (recomendado mesmo sem uso intenso):
- Preferencial, após verificar os logs de acesso: SERVER_MAXHTTPHEADERSIZE=64KB, 200 threads, MPR 50 (nenhuma rodada 64KB ficou sem memória). Capacidade: C_pod ≤ 130 − O (fórmulas 2 e 5).
- Com 10MB necessário: SERVER_TOMCAT_THREADS_MAX=130 (ou menos, pela fórmula 3): sem falta de memória até 220 simultâneas, mas capacidade de cerca de 60 − O (130 − 50 − 20 − O).
- Não aplique os 130 sozinho: cargas de cerca de 110 a 170 simultâneas que hoje funcionam com 200 threads passam a colapsar. Verifique os logs primeiro (com 64KB o corte é desnecessário); se cortar, faça no rollout do aumento de réplicas, ou depois, com C_pod ≤ 60 − O (fórmula 6). Até lá, mais réplicas e -XX:+ExitOnOutOfMemoryError.
- Uso intenso: SERVER_MAXHTTPHEADERSIZE=64KB, SERVER_TOMCAT_THREADS_MAX=400 e MPR 50 (100 só se a fórmula 1 pedir e o node-faas comportar 100 × maxReplicas). O limite passa a ser o banco: C_pod ≤ 180 − K (130 no pior caso com MPR 50); exige a verificação do PostgreSQL. Com 10MB, não há opção viável de uso intenso em 4 GB: aumente heap ou réplicas.
Heap de 6 GB
- Distribuída: no limite. Segura só com base até cerca de 0,4 GB e sem conexões longas relevantes: 200 threads são o teto da fórmula 3 (pico cerca de 85% calculado; cerca de 95% com base de 1 GB, o que leva à falta de memória). Capacidade limitada pelas threads: C_pod ≤ 130 − O no pior caso de chamadas de volta (cerca de 180 − O com chamadas curtas, como nos testes).
- Uso normal: meça a base; se couber, nada a alterar. Senão, 64KB (após os logs de acesso) ou threads pela fórmula 3 com mais réplicas. Não aumente as threads com 10MB.
- Uso intenso: preferencial igual a 4 GB (64KB, 400 threads, MPR 50 ou 100; com 6 GB há mais folga). Com 10MB necessário: no máximo 200 threads (ou a fórmula 3), MPR 50 e réplicas até C_pod ≤ 130 − O; ou heap de 8 GB.
Heap de 8 GB
- Distribuída: memória com folga; o limite são as threads (com as 200 ocupadas, cerca de 64% do heap calculado, cerca de 71% com base de 1 GB).
- Uso normal: nada a alterar; limites de C_pod iguais aos de 6 GB (130 − O).
- Uso intenso: mantendo 10MB, SERVER_TOMCAT_THREADS_MAX=270 e MPR 50 (teto com base 0,4 GB; cerca de 245 com base de 1 GB; pico cerca de 84% num heap real, calculado). Fórmula 2: C_pod ≤ 200 − O (MPR 50) ou 150 − O (MPR 100); fórmula 5: C_pod ≤ 130 (MPR 50) ou 80 (MPR 100) no pior caso; use o menor. MPR 100 não testado com 270 threads. Alternativa, após os logs de acesso: 64KB e 400 threads. Nos dois casos, verifique o PostgreSQL antes de passar de 200 threads.
Ordem das alterações
- Heap: confirme o heap efetivo (-Xmx em JAVA_TOOL_OPTIONS ou JDK_JAVA_OPTIONS, ou limite × MaxRAMPercentage), escolha a faixa e meça a base. Confira também application-*.yml montados (server.max-http-header-size, server.tomcat.threads.max ou o antigo server.tomcat.max-threads) e SERVER_TOMCAT_MAXTHREADS, nome antigo ainda aceito.
- kubectl exec <pod> -- env | grep -E '^(JAVA_TOOL_OPTIONS|JDK_JAVA_OPTIONS|SERVER_MAXHTTPHEADERSIZE|SERVER_TOMCAT_THREADS_MAX|SERVER_TOMCAT_MAXTHREADS|SPRING_CONFIG_[A-Z_]+)=' kubectl get pod <pod> -o jsonpath='{.spec.containers[0].resources.limits.memory}{"\n"}{.spec.containers[0].volumeMounts}{"\n"}'
- Health checks e falta de memória: antes de qualquer aumento de carga, liveness 5 s × 3 e -XX:+ExitOnOutOfMemoryError.
- Logs de acesso: antes de reduzir o cabeçalho, procure requisições acima de 64 KB (Cuidados).
- Cabeçalho antes das threads: aplique SERVER_MAXHTTPHEADERSIZE antes de aumentar SERVER_TOMCAT_THREADS_MAX. Com 10MB, nunca acima do teto da faixa nem da fórmula 3. Redução de threads só com o aumento de réplicas, ou depois. Para voltar a 10MB (ex.: cliente recebendo 400 após 64KB): threads de volta ao teto da faixa antes ou no mesmo rollout (só remover SERVER_MAXHTTPHEADERSIZE com 400 threads exige cerca de 9,6 GB de buffers); antes, considere 128KB ou 256KB.
- PostgreSQL: antes de passar de 200 threads, max_connections e pool de cada tenant (Cuidados).
- Réplicas: HPA (minReplicas e maxReplicas, com a réplica extra) e réplicas do node-faas (fórmulas 4 e 6), antes de aumentar o MPR.
- MPR: só agora, se a fórmula 1 pedir e o node-faas comportar: FAASCLIENT_HTTP_MAXCONNPERROUTE=100.
- Demais FAASCLIENT_HTTP_*: só diante de sintoma (Como ajustar).
Um item por vez (exceto a redução de threads, que acompanha as réplicas); cada alteração exige rollout, fora do pico; observe um pico real antes da próxima.
Como verificar após a alteração
- FaaS: linha FaaS HTTP client sem WARN em seguida. Exemplo com MPR 100:
FaaS HTTP client: maxConnPerRoute=100, maxConnTotal=200, connectTimeoutMs=5000, connectionRequestTimeoutMs=10000, readTimeoutMs=90000, keepAliveMs=2000- Threads e cabeçalho não aparecem no log: use os comandos do item 1 de Ordem das alterações (sem definição, valem 10MB e 200). Para o limite de cabeçalho, envie 70 KB: 400 = rejeitado (como com 64KB); outro status = aceito (com MANAGEMENT_SERVER_PORT, a 8080 responde 404, também aceito).
# em um terminal
kubectl port-forward pod/<pod> 8080:8080
# em outro terminal
curl -s -o /dev/null -w '%{http_code}\n' -H "X-Teste: $(head -c 70000 /dev/zero | tr '\0' a)" http://localhost:8080/lowcode/management/health/readiness- Falta de memória: nenhum OutOfMemoryError (nos testes, Failed to complete processing of a request seguido de java.lang.OutOfMemoryError: Java heap space); se houver, reinicie o pod e revise cabeçalho e threads. Com -XX:+ExitOnOutOfMemoryError, sai Terminating due to java.lang.OutOfMemoryError e o container reinicia (kubectl logs <pod> --previous).
kubectl logs -l app=<nome-do-deployment> --prefix --tail=-1 | grep "OutOfMemoryError"- Health check no pico: readiness abaixo de 1 s (até 169 ms nas rodadas saudáveis); sem eventos Unhealthy nem aumento em RESTARTS. Health check rápido não descarta colapso por pool de banco (até 204 ms nesse colapso): confira as mensagens (Como ajustar). Falta de memória: 2 a 16 s; falta de threads: 12 a 26 s.
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' http://localhost:8080/lowcode/management/health/readiness
kubectl get events --field-selector reason=Unhealthy
kubectl get pods -l app=<nome-do-deployment>
Cuidados
- Cabeçalho de 64KB: antes, procure requisições acima de 64 KB na linha de requisição + cabeçalhos (filtros longos na URL, cookies, tokens); logs de acesso comuns não registram esse tamanho:
- Ingress: $request_length (nginx) ou request.size (Kong), só triagem: incluem o corpo, e pipelines de log truncam linhas longas.
- URL longa conhecida: GET /lowcode/api/secure?jwe=...&client_pub_jwk=... (SDK para SSE).
- Chamadas internas (ex.: node-faas → Low Code) não são registradas: use um pod canário com 64KB e procure Request header is too large.
- O tráfego externo provavelmente já é limitado (ingress nginx: 4 × 8 KB; roteador do OpenShift: cerca de 32 KB); o risco está nas chamadas internas. Cabeçalho de resposta grande (Set-Cookie, Content-Disposition) dá 500 (não testado com 64KB).
- O 10MB existe desde a 0.7.4 sem motivo documentado. Se algum cliente precisar de mais, 128KB ou 256KB (cerca de 100 e cerca de 200 MB com 400 threads; calculado, não testado).
- Conexões longas com 10MB: cada SSE aberto ou requisição recebida em parte custa 22 a 24 MB além das threads, sem limite prático (8192 conexões). Se forem muitas, 64KB.
- PostgreSQL ao aumentar threads: com um tenant ativo por pod, nada muda; com vários, 270 ou 400 threads podem aumentar as conexões por pod na mesma proporção. Confira se max_connections ≥ (maxReplicas + pods extras do rolling update) × (o menor valor entre T + tarefas em segundo plano e a soma dos maximumPoolSize dos tenants ativos no pod, mais os pools de conexões dinâmicas, 100 cada por padrão) + outros clientes + reserva. Confira também o pool de cada tenant (fórmulas 5 e 7). Não aumente APP_DATASOURCE_POOL_MAXIMUMPOOLSIZE para ganhar capacidade de FaaS.
- node-faas: recebe MPR × réplicas do Low Code (com pods do HPA e do rolling update); MPR acima da capacidade só transfere a fila e gera Read timed out.
- Probes: com falta de memória (health check de 2 a 16 s), o liveness de 5 s detecta ainda menos o estado degradado; daí -XX:+ExitOnOutOfMemoryError (encerra no primeiro OutOfMemoryError e o Kubernetes reinicia; não testado). 400 threads é o maior valor testado.
- HPA por CPU: com 64KB e 400 threads, média de 0,5 a 2,1 núcleos (amostra de 4,8; 0,5 a 0,7 no colapso); contra o request de 1 CPU e o alvo de 65% do template, não dá para prever se o HPA cria pods num colapso, e eles somariam conexões e execuções sem resolver. Limite maxReplicas pela fórmula 4 e pelo PostgreSQL.
- Memória do container (MaxRAMPercentage=70): heap de 4 GB exige cerca de 5,7Gi; 6 GB, cerca de 8,6Gi; 8 GB, cerca de 11,4Gi (memória fora do heap não medida).
- Homologação: teste as configurações de uso intenso em homologação, com o runtime de produção do node-faas.
O que cada execução de FaaS ocupa
- Uma thread do Tomcat durante todo o percurso e uma vaga do pool FaaS enquanto aguarda o node-faas.
- Uma conexão do pool de banco do tenant (inferência): padrão de 200 por tenant e por pod (APP_DATASOURCE_POOL_MAXIMUMPOOLSIZE), espera de até 15 s (APP_DATASOURCE_POOL_CONNECTIONTIMEOUT).
- Mais uma thread e uma conexão a cada chamada da função ao Low Code (chamada de volta).
- Heap para buffers de cabeçalho: cerca de 2 × SERVER_MAXHTTPHEADERSIZE por requisição em processamento (qualquer uma, inclusive health checks, seja qual for o tamanho real dos cabeçalhos) e por conexão aberta sem thread (SSE, respostas assíncronas, requisições recebidas em parte). Com 10MB, 22 a 24 MB por requisição, conforme a região do G1 (22 MB medidos com -Xms2g -Xmx4g; 24 MB calculados para -Xms4g -Xmx4g e para heaps de 6 e 8 GB com -Xms2048m). Após um pico, o Tomcat retém até cerca de 200 processadores, sem passar dos que chegaram a ser usados, cada um com os dois buffers (cerca de 200 × 2 × H: 4,4 a 4,8 GB com 10MB; com 130 threads, 2,75 GB vivos mesmo após coleta completa forçada), reaproveitados no pico seguinte.
Fórmulas de dimensionamento
Grandezas, por pod:
- R: réplicas no pico (pior caso: maxReplicas). X_pod (lei de Little) = (pico de execuções/s no cluster ÷ R) × tempo médio da execução em s, com a fila do node-faas.
- C_pod: pico de requisições de FaaS simultâneas, com a fila do pool (cerca de X_pod em regime normal; cresce numa lentidão do node-faas).
- K: chamadas de volta simultâneas, de 0 a MPR; passa de MPR com chamadas paralelas (Promise.all) ou /faas/run (que também ocupa o pool FaaS). O: demais requisições (telas, APIs, integrações).
- S: conexões longas sem thread: SSE (importação e instalação de pacotes do designer, que não expiram; /{bo}/sse; /adapter/sse), streams do SDK por GET /lowcode/api/secure?jwe=... e requisições recebidas em parte; único limite: server.tomcat.max-connections (8192).
- MPR = FAASCLIENT_HTTP_MAXCONNPERROUTE; T = SERVER_TOMCAT_THREADS_MAX; H = SERVER_MAXHTTPHEADERSIZE; Xmx = heap máximo efetivo.
- MPR: MPR = 50 se 1,25 × X_pod ≤ 50; MPR = 100 se 1,25 × X_pod ≤ 100; acima disso, aumente réplicas (fórmula 6). Nunca acima de 100 (150 gerou de 136 a 146 Read timed out, de 43 a 361 erros de banco ou de autenticação e fila de até 250 no node-faas). Mantenha MPR ≤ T ÷ 2. Cada pod atende no máximo cerca de MPR ÷ tempo médio da execução execuções/s.
- Threads: T ≥ C_pod + K + O + 20 (health checks e folga). Acima de T, health check de 12 a 26 s e sucesso de 17% a 38%, mesmo com memória sobrando.
- Heap: pico ≈ base + P × custo, com P = requisições em processamento (até T) + S. Custo: 24 MB com 10MB; cerca de 0,13 MB com 64KB (400 threads ≈ 50 MB; mil conexões longas ≈ 130 MB).
- Base: meça a do ambiente (G1 Old Gen logo após uma coleta, sob carga normal), de preferência num pod com 64KB: com 10MB, a medida inclui os buffers retidos do maior pico, a descontar. No teste, 0,18 a 0,41 GB (0,4 GB é a escolha conservadora usada abaixo); em produção (vários tenants, caches, respostas grandes), pode chegar a cerca de 1 GB.
- Folga-alvo de 15%: T ≤ (0,85 × Xmx − base) ÷ 24 MB − S. Base 0,4 GB e S = 0: cerca de 130 (4 GB), 200 (6 GB), 270 (8 GB), os tetos das faixas. Base 1 GB: cerca de 100, 175 e 245 (200 threads em 6 GB chegam a cerca de 95% e 270 em 8 GB a cerca de 92%; nos dois casos, falta memória). Sem medir base nem S, use 0,75 (cerca de 110, 175 e 240) ou 64KB.
- Folga medida nos tetos: pico da geração antiga de 77,5% (4 GB, 130 threads), 88,1% (6 GB emulado, 200) e 87,0% (8 GB emulado, 270); folga de 12% a 13% nas emulações, estimativa de 82% a 85% num heap real; somando os objetos temporários, o uso chegou a 93,5%.
- node-faas: MPR × (maxReplicas do Low Code + pods extras do rolling update) ≤ réplicas do node-faas × execuções simultâneas seguras por réplica. O runtime 1.x não limita execuções simultâneas: meça essa capacidade em teste de carga.
- Banco, por tenant e por pod: C_pod + K + demais usos do banco ≤ 90% do pool do tenant (180 com o padrão de 200); margem de planejamento, não limite medido. pool.maximumPoolSize e pool.connectionTimeout do recurso de banco (DATABASE) do tenant prevalecem: confira em cada tenant.
- Réplicas: C_pod_alvo = maior C_pod que atende 2, 3 e 5; minReplicas = arredondamento para cima de (pico de execuções simultâneas no cluster ÷ C_pod_alvo) + 1. A réplica extra cobre um pod a menos: com o maxUnavailable de 25% do template, num rolling update ou perda de pod os demais recebem até cerca de 1/3 a mais (ou use maxUnavailable: 0). Rollouts fora do pico.
- Espera na fila: 10000 ≤ FAASCLIENT_HTTP_CONNECTIONREQUESTTIMEOUTMS < menor espera do pool de banco entre os tenants (APP_DATASOURCE_POOL_CONNECTIONTIMEOUT, padrão 15000, ou pool.connectionTimeout). Tenant com pool.connectionTimeout abaixo de 10000 quebra a regra já com o padrão (401 e 403 enganosos): ajuste-o para pelo menos 15000.
Exemplo: 3 réplicas, 120 execuções/s, 1,5 s por execução, K até MPR, O = 20. X_pod = (120 ÷ 3) × 1,5 = 60; 1,25 × 60 = 75 > 50 → MPR = 100; threads 60 + 100 + 20 + 20 = 200, acima do teto de 130 (4 GB com 10MB): 64KB com 400 threads ou heap de 8 GB com 270 (fórmula 5: 160 ≤ 180). Com 6 réplicas: X_pod = 30, MPR = 50, threads 120; C_pod_alvo = 130 − 50 − 20 − 20 = 40, minReplicas = ⌈(120 × 1,5) ÷ 40⌉ + 1 = 6. Escalar horizontalmente costuma ser o mais simples.
Validação
Ambiente: uma máquina (32 núcleos, sem limite de CPU), um Low Code 1.18.4, um node-faas (runtime 2.x, até 4 funções por vez, cerca de 24 a 45 execuções/s) e um tenant. Função de teste: consulta a objeto de negócio (100 a 150 ms) que chama o Low Code. Clientes em ciclo fechado ("simultâneas × execuções por cliente"); JVM -Xms2g -Xmx4g (G1, regiões de 1 MB); readiness medido a cada 1 s; lentidão simulada com +1,5 s por chamada. Nas rodadas por faixa de heap, percentuais = geração antiga; nas demais, valores em GB = heap total com objetos temporários (com 64KB, geração antiga até 0,4 GB).
Heaps de 6 e 8 GB emulados (sem memória livre na máquina): heap de 4 GB com 7400KB (16 MB por requisição, 4/6 de 24 MB) e 5120KB (12 MB, 4/8). Os 24 MB num heap real de 6 ou 8 GB são calculados (supondo -Xms2048m), não medidos; como a base pesa mais em 4 GB, heaps reais teriam um pouco mais de folga. Uma primeira emulação de 6 GB com 6826KB (14 MB, cerca de 12,5% otimista) teve 97,9%, 98,8% e 37%.
Distribuída (10MB, 200 threads), 4 GB, seis configurações do pool FaaS (padrão; esperas de 5, 20 e 30 s; MPR 25 e 100)
- 100 × 6: 100%, heap até 2,73 GB. 150 × 6: 99,1% a 100% (espera de 5 s: 96,1%), geração antiga em 93% (97% a 98% com temporários).
- 180 × 6: OutOfMemoryError nas seis em 2 a 4 s; 82,9% a 92,5%; 50% a 65% do tempo em coleta; health check até 4,1 s.
- Nenhum MPR ou espera mudou esse ponto. Abaixo dele, MPR 100 teve p95 de 4,9 s com 150 (padrão: 6,8 a 9,6 s).
Faixas com 10MB (14 medições, espera de 10 s)
- 4 GB, 130 threads (medido): até 77,5%, sem falta de memória até 220. 130 simultâneas: 89,7% (health check de 12,9 s); 180: 32,9% e 12 Read timed out (só 367 das 1.080 chamadas chegaram ao node-faas, por falta de threads para as chamadas de volta); 220: 26,9%, 34 Read timed out (até 26,2 s).
- 6 GB, 200 threads (emulado): 150 e 180: 99,2% e 99,4% (até 80 ms); 220: 38,3% (até 13 s; 88%). Heap real de 6 GB (rodada anterior, fora das 14 medições; não registrou coleta de lixo nem espera na fila): 100% com 150 e 180, health check abaixo de 150 ms.
- 8 GB, 200 threads (emulado): 180: 98,4% (até 98 ms); 220 e 260: 37% e 29,9% (até 13,7 s); até 63%.
- 8 GB, 270 threads (emulado): 220 e 260: 86,2% e 84,6%, até 124 ms, falhas só por fila; pico de 87%.
- Nenhuma falta de memória, coleta completa ou erro de banco; Read timed out só com 130 threads.
- Modelo de memória: a fórmula 3 previu a memória após o pico com erro de até 3,2%, mas, com a base do pod ocioso (102 a 121 MB), ficou abaixo do pico medido nas 14 medições (geração antiga de 2,4% a 10% acima do previsto). Requisições em processamento = menor valor entre as threads e "simultâneas + cerca de 5" (chamadas de volta e health checks).
64KB e 400 threads, 4 GB (MPR 50, 100 e 150 com 10 s; MPR 100 com 20 s)
- Cabeçalho: 60.000 bytes, 200; 70.000 e 200.000, 400; token na URL (cerca de 1,7 KB), 200.
- 180 × 6: 99,4% a 100%, health check até 115 ms, heap até 1,44 GB.
- 300 × 4: colapso (35,9% a 55,9%). MPR 50: 43%, só falhas por fila, health check até 99 ms (só cerca de 8 execuções/s chegaram ao node-faas, contra cerca de 38 com 180; causa não diagnosticada). MPR 100: 62 Read timed out; MPR 150: 136 Read timed out e 43 erros de banco ou de autenticação; 20 s: 405 desses erros (198 403 Access Denied) e 364 por fila.
- 420 × 3: 16,6% a 29%, health check de 12,1 a 14,3 s, heap até 1,53 GB. MPR 100: 91 Read timed out; MPR 150: 146 Read timed out, 361 erros de banco ou de autenticação e fila de 250 no node-faas; 20 s: 599 erros (352 403 Access Denied) e 296 por fila.
- MPR 100 dobra as chamadas simultâneas enviadas ao node-faas (de 51 para 101; o runtime local executou no máximo 4 por vez): melhora vazão e tempo abaixo do limite, mas sob sobrecarga gerou de 62 a 91 Read timed out.
- Colapso entre 260 (270 threads) e 300 simultâneas (400 threads), em configurações diferentes; atribuí-lo ao pool de banco é inferência (PostgreSQL com 198 a 207 conexões desde 180 simultâneas; em 4 de 6 thread dumps, chamadas ao node-faas + esperas na fila = exatamente 200). Com 300, nenhum MPR ou espera o evitou.
node-faas lento, 4 GB
- 10MB, 200 threads: 100% com 60 e 120 (espera de 5 s com 120: 96,7%); com 120, geração antiga já em 3,0 a 3,1 GB (3,1 a 3,2 GB de heap total); 220: OutOfMemoryError, 22,7% a 52,4%, 70% a 79% em coleta, health check de 11,4 a 16,3 s.
- 64KB, 200 threads, MPR 50: 100% com 60 e 120 (heap de 1,2 a 1,3 GB); 220: 37,4% e 13,3 s (threads).
- 64KB, 400 threads, MPR 100: 100% com 60 e 120 (33,6 execuções/s, contra 26,1 com MPR 50 e 200 threads); 220: 84,8%, até 101 ms.
Espera na fila: 5 s perdeu 3,9% com 150 e 3,3% com 120 e node-faas lento; 10 s, 0 a 2,1% até 180 (0 a 1,6% sem a primeira emulação de 6 GB); 20 s gerou os erros de banco e de autenticação acima; 30 s, com 300 simultâneas, levou o health check a 32,9 s (11% de sucesso, 81% de falhas por fila e 8% de Read timed out; rodada de 222 s). Este resultado e o de 5 s com 150 simultâneas (89% de sucesso, 11% de falhas por fila) vêm das primeiras rodadas, antes de fixar o heap em 4 GB, e não são diretamente comparáveis.
Reutilização de conexões ociosas (comportamento do Node.js 20): sem limite, falhas numa faixa de cerca de 2 ms abaixo de 5 s de ociosidade (179 em 4.100 tentativas; nenhuma falha em 2.700 tentativas com pausas fixas entre 3,9 e 5 s) e, com travamentos de cerca de 0,9 s, a partir de 4,5 s. Limite de 4 s: nenhuma falha em 6.800 tentativas sem travamento, mas travamentos de 1,5 s ou mais ainda falharam. Limite de 2 s: travamentos de até 2,9 s sem falhas. O ambiente local (Node.js 24, que mantém a conexão 1 s além do anunciado) não reproduziu o problema em 84 execuções.
Resultado: nenhuma execução ficou presa indefinidamente, ao contrário das 1.18.1 a 1.18.3.
O que não foi medido
- Produção: runtime 1.x, várias réplicas, vários tenants por pod, max_connections, pools por tenant fora do padrão, base de memória real e conexões longas sob carga.
- Heaps reais de 6 e 8 GB no limite; 64KB com 6 e 8 GB; limite de CPU de 2 núcleos (a média de 2,1 e o pico de 4,8 já o passam); memória fora do heap e OOMKilled.
- Threads diferentes de 130, 200, 270 e 400; MPR acima de 150; MPR 100 com 270 threads e nas rodadas por faixa de heap; espera de 11 a 14 s; 128KB e 256KB; -XX:+ExitOnOutOfMemoryError; os demais parâmetros sob carga e o APP_HTTPCLIENT_*.
- Cabeçalhos de resposta grandes com 64KB; /faas/run; chamadas de volta paralelas; chegada contínua de requisições numa lentidão (testes em ciclo fechado, até cerca de 4 chamadas de volta simultâneas; o proxy de atraso não ocupou worker do node-faas nem thread de chamada de volta): funções lentas ou com muitas chamadas ao Low Code podem esgotar threads e conexões antes do medido.
- Probes no Kubernetes real: só o tempo do readiness, com sondagem sequencial. Com falta de memória, travamentos de 2 a 16 s; de 2 a 7 sondagens por nível passaram de 1 s (timeout do liveness do template) e de 5 a 47 não retornaram 200; reinício pelo liveness possível, não testado.
Os números são de um ambiente de desenvolvimento e servem como referência de comportamento, não de capacidade de produção.
