Dissecando o Magic xpi 4 - Workers

Dissecando o Magic xpi 4 – Workers

(agora com GigaSpaces) 

Captura de Tela 2014-03-13 às 12.41.34 AM

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.iStock_000017351445Large[1]1234554321

(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:

 Dissxpi4W_Imagem_001

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:

 Dissxpi4W_Imagem_002

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:

 Dissxpi4W_Imagem_003

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:

 Dissxpi4W_Imagem_004

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:

 Dissxpi4W_Imagem_005

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.

 

Manoel Frederico – Evangelista de Tecnologia e Gerente de Produto

Comentários2 Comments

  1. Carlos disse:

    Cuales son los Costos de de Magic XPI.V4?

    • Magic Brasil disse:

      Hola Carlos,

      Não há custo para quem tem contrato de manutenção ativo da licença em versão anterior, caso seja uma licença nova isso depende do projeto, temos que realizar uma avaliação antes de precipitar.

      Te contataremos em seu email para isso.

Novo Comentário