Este guia descreve as melhores práticas para projetar aplicativos Tulip de alto desempenho que se expandam com eficiência em ambientes de produção. Seguir essas recomendações ajudará a garantir que seus aplicativos permaneçam responsivos e estáveis, mesmo à medida que sua operação crescer.
As recomendações deste artigo se aplicam sempre que suas soluções incluírem o uso de Funções de Conector para a API do Tulip. Entre elas estão:
- Execuções de funções de conexão ou chamadas de API ( API Call) em gatilhos no nível do aplicativo (temporizador, botão, entrada de etapa, por exemplo)
- Chamadas de API do Node-RED
- Scripts com chamadas de API originadas fora das soluções Tulip
- Gravações em tabelas do Tulip usando a API de tabelas a partir de outros sistemas
O que é um gatilho de alta frequência?
Um gatilho de alta frequência é executado com frequência superior a a cada 5 segundos (mais rápido que 0,2 Hz). Eventos de atributos de máquina, eventos de dispositivos e gatilhos de temporizador são as fontes mais comuns de execução de alta frequência.
A Tulip recomenda que os gatilhos não sejam executados com frequência superior a 5 segundos (0,2 Hz) para manter o desempenho e a capacidade de resposta do aplicativo.
Impacto na fila de gatilhos
Os gatilhos do aplicativo são executados de cima para baixo em uma fila sequencial de thread único, conhecida como fila de gatilhos.

Dois fatores determinam se a fila opera com eficiência:
- Taxa de entrada na fila: com que frequência os eventos de gatilho são adicionados à fila
- Taxa de saída da fila: a rapidez com que a lógica do gatilho conclui a execução
Quando os gatilhos entram na fila mais rápido do que saem, a fila fica congestionada. O congestionamento contínuo da fila de gatilhos causa latência no aplicativo e, em alguns casos, a perda de eventos de gatilho.
Pense na frequência dos gatilhos como o tráfego em uma rodovia. Se muitos carros entrarem na rodovia em um curto período de tempo, o tráfego fica lento. Para evitar o acúmulo, os carros devem entrar a uma taxa que a rodovia possa acomodar.
Frequência combinada
A taxa combinada de todos os eventos de acionamento em um aplicativo determina a taxa geral de entrada na fila. Cada evento de acionamento que você configura contribui para essa taxa combinada.
Veja a tabela abaixo para exemplos de frequência combinada:
| Configuração | Frequência combinada |
|---|---|
| 1 atributo da máquina atualizado a cada 1 segundo | 1 Hz |
| 5 atributos da máquina atualizados a cada 1 segundo | 5 Hz |
| 1 atributo da máquina (1 s) + 1 temporizador (2 s) | 1,5 Hz |
Escala de velocidade da lógica de acionamento
O tipo de lógica de acionamento determina a rapidez com que os acionadores saem da fila. Lógicas que exigem comunicação com a nuvem, transições ou respostas de sistemas externos levam significativamente mais tempo para serem executadas do que operações locais.
A tabela abaixo descreve a velocidade dos diferentes tipos de lógica.
For high-frequency triggers, aim to use only logic rated Very fast or Fast.
| Velocidade | Tipo de lógica | Exemplos |
|---|---|---|
| Muito rápida | Lógica de aplicativo local | Leitura ou atualização de dados locais (por exemplo, variáveis) |
| Rápido | Dados na nuvem armazenados em cache | Leitura de registros de tabela já carregados |
| Médio | Tulip Cloud | Carregamento, atualização ou criação de registros da tabela; leitura ou atualização do estado da máquina |
| Lento | Tulip Cloud | Agregações e consultas em tabelas |
| Muito lento | Sistemas externos | Funções do conector |
There is currently no easily accessible app performance log available for evaluating trigger performance. App performance can only be inferred through step times in completion records, which is useful in cases where steps involve extensive looping.
Fatores técnicos que afetam o desempenho dos gatilhos
- Hardware local — A lógica do gatilho é executada no hardware local e, portanto, as especificações do dispositivo afetam significativamente a rapidez com que os gatilhos são concluídos e saem da fila. Para obter informações sobre as especificações do dispositivo, consulte Dispositivos recomendados para o Tulip Player.
- Dependências externas — As dependências externas incluem a conectividade com a nuvem, a latência da rede local e o tempo de resposta de sistemas externos, como o Planejamento de Recursos Empresariais (ERP).
- Dispositivos conectados por meio de dispositivos Tulip Edge — Os aplicativos Tulip dependem da conectividade com a nuvem, o que pode causar latência. Por exemplo, um controlador de torque conectado a um dispositivo de borda ainda se comunica com o Tulip Player por meio dos serviços em nuvem da Tulip. Para entender as conexões dos dispositivos, consulte estes diagramas de sequência para conexões de dispositivos por meio de drivers Tulip.
- Problemas de latência com funções de conector — A resposta lenta de um sistema (por exemplo, um ERP) por meio de uma função de conector pode causar atrasos no aplicativo, especialmente se o aplicativo percorrer muitos registros, cada um exigindo uma chamada de API que pode levar até dois segundos. Para entender as conexões do sistema, consulte estes diagramas de sequência para conexão com sistemas corporativos.
- Latência entre o chão de fábrica e a infraestrutura em nuvem da Tulip — Para minimizar a latência, sua instância da Tulip está localizada na mesma região geográfica que seu chão de fábrica.
Orientações
Evite gatilhos de alta frequência
Você deve evitar gatilhos de alta frequência sempre que possível e, em vez disso, usar outros recursos, como as “ Automations”.
Você também pode querer reprojetar a arquitetura do seu aplicativo para operar em uma taxa mais baixa. Por exemplo:* Relatórios de dados menos frequentes com consultas e agregações* Para casos de uso assíncronos, o looping pode ser realizado por meio de Automations* Para casos de uso síncronos, o looping que deve ser feito sequencialmente deve ser realizado por meio de Functions
Se for necessário usar um gatilho de alta frequência, configure-o para executar apenas tarefas locais (por exemplo, atualizar uma variável do aplicativo). Em seguida, use um gatilho de baixa frequência para as execuções mais lentas (por exemplo, atualizar um registro da tabela).
Se você estiver usando um gatilho de temporizador de alta frequência para reagir rapidamente a um contexto fora de um aplicativo Tulip, talvez seja possível usar uma “Event Stream” Tulip Machine com gatilhos de máquina e de dispositivo.
Uso das APIs de tabela do Tulip
O uso de APIs de tabela para ler ou gravar várias vezes por segundo pode afetar o desempenho da sua instância e causar atrasos na leitura ou no armazenamento de dados. As recomendações abaixo se aplicam a todos os scripts e ações de gatilho que executam APIs do Tulip em uma instância do Tulip:
Recomendação
- Planeje a execução de sua lógica para respeitar os limites de taxa das tabelas do Tulip
- Evite gravações frequentes no mesmo registro de uma tabela (mais de 1 por segundo)
Quando os limites forem excedidos, o Tulip poderá aplicar um limite de taxa e retornar o código de erro 429. Os scripts devem ser resistentes a códigos de erro 429 para tentar novamente após um intervalo.
Gatilhos de máquina, dispositivo e temporizador
Gatilhos de temporizador com intervalos curtos (a cada 1–2 segundos) podem sobrecarregar seus aplicativos, especialmente quando incluem várias chamadas de API (por exemplo, gravações em tabelas ou execuções de funções de conectores).
Tulip no longer supports a timer trigger with <30sec frequency. For timer triggers used in an event-based architecture (i.e. a table record field changed or the current time is 7:00am), we recommend using Machines or [Automations]. Contact your Tulip representative if you have questions about this transition.
Os gatilhos de máquina monitoram alterações de atributos em equipamentos conectados e executam lógica em resposta. Quando um relatório d machine attributes a em alta frequência ou quando vários atributos são monitorados simultaneamente, a execução do gatilho pode exceder a taxa na qual o aplicativo processa os gatilhos. Isso pode levar à degradação do desempenho.
Recomendação
- Limite as assinaturas d machine attribute s apenas àquelas necessárias para a etapa ou fluxo de trabalho atual
- Separe a lógica de alta frequência das operações na nuvem e use um gatilho de menor frequência para lidar com ações dependentes da nuvem
Cenário de exemplo: Um “ machine attribute ” é atualizado 4 vezes por segundo, e você precisa rastrear a contagem de atualizações em um registro da tabela. Gatilho 1 (evento de máquina): Atualizar uma variável do aplicativo com os dados de máquina recebidos. Gatilho 2 (temporizador, a cada 10 segundos): Gravar os dados acumulados em um registro da tabela
| Abordagem | Configuração | Desempenho |
|---|---|---|
| Ótimo | O gatilho da máquina incrementa a variável do aplicativo; o gatilho do temporizador grava na tabela a cada 10 segundos | Bom (operação na nuvem a 0,1 Hz) |
| Lento | O acionamento da máquina grava diretamente na tabela a cada atualização | Ruim (operação na nuvem a 4 Hz) |
- Considere usar automações para processamento assíncrono a fim de remover a carga de processamento da fila de gatilhos. Por exemplo, se os dados da máquina precisarem ser processados, mas não exigirem feedback imediato do operador na sessão do aplicativo
- Use apenas operações rápidas nos gatilhos, como “Ler/atualizar variáveis do aplicativo” ou “Ler registros da tabela”
- Avalie a arquitetura do seu aplicativo e considere reprojetá-la para operar em uma taxa mais baixa se o seu caso de uso exigir o monitoramento de muitos atributos em altas frequências. Abordagens alternativas incluem:
- Agregar dados no nível da máquina ou do dispositivo de borda antes de enviá-los ao Tulip
- Use automações para coleta e processamento de dados
- Reduzir a frequência de envio de relatórios na fonte de dados
- Considere usar drivers do Tulip Player em vez de drivers hospedados em dispositivos de borda
- Driver do Player da ferramenta Torque
{{snippet.Você encontrou o que estava procurando?}}


