Como processar grandes volumes de dados no Protheus sem sobrecarregar as threads do AppServer ou estourar a memória de strings?
Desenvolvemos o **hbBridge** para atuar como um executor nativo de alta performance para o ERP, integrando o Protheus (AdvPL/TLPP) a um motor em **Harbour, C e Zig**.
🔹 **Como funciona a arquitetura?**
• O **Protheus** permanece como o maestro do negócio: resolve empresas, `xFilial`, permissões e dicionários (SX3).
• O **hbBridge** atua na execução pesada: consultas paginadas direto no SGBD (`ROW_NUMBER()` no MSSQL), multithreading e rotinas dinâmicas (`.hrb`) sem restart de serviço!
• O **Contrato HBBRIDGE/1** opera em memória com gzip bilateral (`GzStrComp`/`zlib`), eliminando arquivos temporários no disco do servidor.
📊 **E na prática? Rodamos o benchmark oficial com MSSQL:**
Avaliamos a travessia de 10.000 registros paginados (100 linhas por RPC) sobre o SQL Server (`MSSQL/pData`):
🟢 **TCP Nativo (Socket):** Média de **311,42 ms** (pico de 279,71 ms)
🟣 **HTTP/REST (FWRest):** Média de **464,40 ms** (pico de 449,82 ms)
⏱️ **Run completa:** 5,49 s para 10.000 linhas em 100 chamadas RPC (incluindo warmup e checagem de dados).
**O que isso ensina?**
O TCP foi **~33% mais rápido** no tempo total de resposta. A camada HTTP adicionou em média ~15,3 ms por página de 100 linhas. Para integrações service-to-service e rotinas críticas, a economia acumulada de CPU e latência no TCP é expressiva.
👉 *Confira o carrossel completo com os diagramas da arquitetura e as tabelas estatísticas detalhadas!*
🔗 Projeto mantido open-source no GitHub: **naldodj/hb.bridge**
Como você tem arquitetado rotinas pesadas no seu Protheus? Costuma usar sockets dedicados ou mantém tudo em REST? Deixe sua experiência nos comentários! 👇
---
**DNATech, #TOTVS, #Protheus, #TLPP, #AdvPL, #Harbour, #ZigLang, #MSSQL, #SoftwareArchitecture, #Performance, #Backend, #DevOps, #Benchmark,**
---
Comentários
Postar um comentário