(agora com GigaSpaces) 

Desde a chegada do Magic xpi versão 4, agora integrado ao GigaSpaces (XAP 9.1.2) – uma plataforma ‘cloud ready’ para aplicações (In-Memory DataGrid, Big Data, Clusters, etc…) – algumas novidades relativas a arquitetura passaram a exigir nossa atenção.

(veja este webcast sobre o Magic xpi 4)

De repente, uma onda de novos termos como Space, Worker, Process Unit, IMDG, Self Healing e etc, entraram no vocabulário do dia-a-dia do Magic xpi. De fato, um simples incremento no número da versão pode não fazer justiça a todas as novidades que ocorreram nos bastidores do Magic xpi. Houve um grande salto no backend dos servidores, da versão 3x para a 4x.

Por isso, vamos analisar individualmente alguns destes novos atores da arquitetura para que toda esta nova estrutura, que é poderosa, seja também fácil de compreender.

A como primeiro item, vamos eleger um termo que tem sido mencionado em várias apresentações, da nova versão: o Worker.

 

O que é um Worker?

 

O Worker é uma thread do Magic xpi Server, que executa fluxos de integração.

Simples assim, como você pode observar neste slide da apresentação do Magic xpi versão 4:

 

Podemos seguramente dizer que:

Worker = Thread

Diante desta sentença, podemos concluir que o Worker não é uma novidade. Ele sempre existiu, pois o Magic xpi desde sua versão 1.0 (quando ainda se chamava iBolt) sempre executou seus fluxos de integração em threads individuais dentro do processo do Magic xpi Server (MgxpiServer.exe). A novidade realmente é que agora essas threads ganharam um nome: Workers. E existem alguns motivos para todo este destaque.

 

O que precisamos saber sobre Worker?

 

Até a versão 3.4 do Magic xpi, ainda na arquitetura de Broker, estas threads de execução eram gerenciadas internamente. Nasciam quando surgia a demanda de execução de algum fluxo do projeto, e eram destruídas assim que este fluxo terminasse sua execução. Havendo necessidade de se executar outro fluxo, ou o mesmo fluxo outra vez, uma nova thread era criada e assim por diante. O total de threads “vivas” simultaneamente (existindo e trabalhando ao mesmo tempo) era limitado pela licença em uso pelo Magic xpi Server. Considerando o exemplo abaixo:

 

Haveria no máximo 4 threads (Workers) ativas ao mesmo tempo, para uso pelo projeto.

Agora na versão 4x, nós é que decidimos quantos Workers (threads) existirão por servidor, para o projeto. Isso é definido no arquivo Start.xml:

 

No exemplo acima, foram definidos 10 Workers (threads) para cada Magic xpi Server (neste exemplo é um MgxpiServer.exe apenas, pois “NumberOfInstances” está = 1).

Ou seja: um Magic xpi Server iniciará a executar na máquina “FZNOTE” dedicado ao projeto “WSOnClusterCheck” e ele terá 10 threads para executar os fluxos.

Um dos motivos que precisamos definir agora, explicitamente, o número de Workers (threads) por cada projeto, é porque eles possuem uma vida útil diferente: Estas threads (Workers) são criadas quando o Magic xpi Server inicia a executar e se mantem “vivas” por todo o tempo. Os Workers (threads) não são mais criados e destruídos sob demanda como nas versões anteriores.

Estes Workers (threads) na versão 4 ficam sempre ativos e constantemente vão até o MAGIC_SPACE (dentro do GigaSpaces), em busca de “trabalho” a realizar. Quando um fluxo de integração precisa ser executado, esta demanda gera um Work Message dentro do MAGIC_SPACE, à espera de algum Worker. O primeiro que se apoderar deste Work Message se torna então a thread encarregada de executar o referido fluxo de integração.

Por causa deste comportamento de pooling é que as threads do projeto são criadas na inicialização do Magic xpi Server e não são destruídas após o término das execuções dos fluxos.

 

Qual a relação do Worker com a Licença?

 

Quando um Worker (thread) se apossa de um Work Message no MAGIC_SPACE, ele precisa fazer uma coisa antes de efetivamente começar a executar o fluxo de integração: check-out da licença. E este check-out é limitado ao máximo de threads simultâneas que a feature da licença determina. Considerando o exemplo abaixo:

 

Mesmo que sejam definidos 10 Workers (threads) para um projeto, e que exista efetivamente a demanda de se executar 10 fluxos de integração simultaneamente em algum momento, apenas 8 threads (Workers) trabalharão ao mesmo tempo: os outros 2 ficam aguardando que algum dos 8 faça check-in da licença em uso (devolvendo-a para o pool), para então poderem iniciar a executar seus fluxos de integração. Logo, mesmo que possamos arbitrariamente definir qualquer quantidade de threads (Workers) para um projeto, o total em execução simultânea segue sendo controlado pela licença.

 

Quantos Worker devem ser definidos por projeto?

 

Esta é a receita de bolo que todos procuram.

Primeiro, considerando o que foi dito até agora, podemos concluir que:

• Workers de menos (menor que o limite da licença), é desperdiçar licença disponível. Exceto se você possuir vários projetos, onde a licença será compartilhada entre todos. Mesmo assim, a soma de todos os Workers (threads) de todos os projetos precisa ser no mínimo igual aos limites das licenças em uso por estes projetos. Senão, estaremos subutilizando a capacidade disponível de processamento paralelo.
• Workers de mais (1000, 5000, 20000) é exagero, consumo desnecessário de recursos da máquina. Exceto se você possuir um super hardware e uma licença que permita estes altos limites de check-out. Nunca haverá mais Workers (threads) executando fluxos simultaneamente do que a soma dos limites das licenças em uso.

Se o que você deseja é uma regra geral, vou sugerir uma:

#Workers = MAX( 8, <limites licenças> + 30% )

Então, se fôssemos configurar 1 projeto para uma licença de 4 threads, definiríamos 8 Workers. Já 1 projeto para uma licença de 8 threads, seriam 11 ou 12 Workers.

Em compensação, observe este arquivo Start.xml:

 

Ele define 2 projetos (“A” e “B”), cada um com o 1 Magic xpi Server. Um deles com 10 Workers (threads), e ou outro com 15.

Na corrida pelo check-out da licença, são 15 contra 10.

Supondo que haja uma demanda de 20 fluxos simultâneos em cada projeto num mesmo momento, estamos dando ao projeto “B” 50% a mais de chances de ter seus fluxos atendidos (numa conta à grosso modo, obviamente).

Resumindo: tornamos o projeto “B” mais prioritário/relevante que o projeto “A”.

Existem outras estratégias de priorização entre projetos, como a reserva de threads (Workers), mas isso será abordado em outra oportunidade.

Mas devemos observar que: manipular o número de Workers (threads) por projeto nos permite também aumentar ou diminuir a carga de processamento que um projeto pode consumir.

 

Porque ter mais Workers que o limite da Licença?

 

Não ter menos Workers (threads) do que os limites permitidos pelas licenças em uso é uma coisa simples de se entender.

Mas porque teríamos mais threads (Workers) do que os limites das licenças, já que a licença controla o número de Workers (threads) trabalhando simultaneamente?

A resposta é: disponibilidade.

Ter Workers (threads) demais é sobrecarregar o sistema. Mas ter apenas o número justo é trabalhar no limite da segurança.

Considere a seguinte situação: um projeto está executando com uma licença de no máximo 4 threads simultâneas, e para ele foram definidos 4 Workers (threads). Se em algum momento houver uma pane nas threads (Workers) #3 e #4, e elas forem abortadas, o sistema de Self Healing do Magic xpi versão 4 é responsável por detectar esta anormalidade e criar dois novos Workers (threads) em substituição a estes dois que “se foram”. Mas isso leva um tempo “x” e enquanto não acontece, teremos apenas 2 threads (Workers) atendendo ao projeto.

Mas, se definirmos 6 Workers (threads) para este mesmo projeto e esta mesma licença, quando os Workers (threads) #3 e #4 “sumissem” o #5 e #6 passariam a se apropriar dos Work Messages no lugar daqueles outros, e do ponto de vista do desempenho geral da execução do projeto, o impacto seria diminuído.