Tenho um novo projeto para armazenar informações de respostas REST em um banco de dados IRIS. Precisarei sincronizar informações de pelo menos duas dúzias de endpoints REST separados, o que significa criar quase essa quantidade de classes ObjectScript para armazenar os resultados desses endpoints.

Como todos sabemos, a InterSystems é uma ótima empresa.

Seus produtos podem ser tão úteis quanto complexos.

No entanto, nosso orgulho às vezes nos impede de admitir que talvez não entendamos alguns conceitos ou produtos que a InterSystems nos oferece.

Hoje estamos começando uma série de artigos explicando como alguns dos intrincados produtos da InterSystems funcionam, obviamente de forma simples e clara.

Neste ensaio, irei esclarecer o que é Machine Learning e como tirar proveito dele... porque desta vez, VOCÊ VAI SABER com certeza do que estou falando.

Às vezes, clientes precisam de uma pequena instância IRIS para fazer algo na nuvem e desligá-la, ou precisam de centenas de contêineres (ou seja, um por usuário final ou um por interface) com pequenas cargas de trabalho. Este exercício surgiu para ver quão pequena uma instância IRIS poderia ser. Para este exercício, focamos em qual é a menor quantidade de memória que podemos configurar para uma instância IRIS. Você conhece todos os parâmetros que afetam a memória alocada pelo IRIS?

Ao trabalhar com InterSystems IRIS, desenvolvedores e arquitetos de banco de dados frequentemente enfrentam uma decisão crítica: usar Dynamic SQL ou Embedded SQL para consultar e atualizar dados. Ambos os métodos têm seus pontos fortes e casos de uso únicos, mas entender suas implicações de desempenho é essencial para fazer a escolha certa. O tempo de resposta, uma métrica chave na avaliação do desempenho de aplicações, pode variar significativamente dependendo da abordagem SQL utilizada. Dynamic SQL oferece flexibilidade, pois as consultas podem ser construídas e executadas em tempo de execução, tornando-o ideal para cenários com necessidades de consulta imprevisíveis ou altamente variáveis. Por outro lado, Embedded SQL enfatiza a estabilidade e a eficiência ao integrar código SQL diretamente na lógica da aplicação, oferecendo tempos de resposta otimizados para padrões de consulta predefinidos.

Neste artigo, explorarei os tempos de resposta ao usar esses dois tipos de SQL e como eles dependem de diferentes estruturas de classe e do uso de parâmetros. Para fazer isso, usarei as seguintes classes do diagrama:

Tenho certeza de que a maioria de vocês está familiarizada com a utilidade %SYS.MONLBL, que é crucial ao analisar gargalos de desempenho de código. Ela permite que você selecione várias rotinas que deseja monitorar em tempo de execução e também especifique qual(is) processo(s) você quer observar. MAS, e se você não souber exatamente qual processo executaria seu código? Isso é verdade para muitos aplicativos baseados na web (CSP/REST) hoje. Você quer minimizar a utilização de recursos em seu sistema de produção que precisa de análise.

Depois que implementamos um novo container baseado em containers.intersystems.com/intersystems/irishealth:2023.1 esta semana, percebemos que nosso FHIR Repository começou a responder com um Erro 500. Isso aconteceu devido a violações de PROTECT no novo namespace e banco de dados HSSYSLOCALTEMP utilizado por essa versão dos componentes FHIR do IRIS for Health.