Weknow
WeDocs-4.4
WeDocs-4.4
  • WeDocs
  • RELEASE NOTES
    • Release Notes 4.4
    • Release Notes 4.3
    • Release Notes 4.2
    • Release Notes 4.1
    • Release Notes 4.0.210
    • Release Notes 4.0
    • Release Notes 3.3
    • Release Notes 3.2
    • Release Notes 3.1
    • Release Notes 3.0
  • CLIENT DESKTOP
    • Instalação
    • Atualizar versão
    • Alteração idioma
    • Cadastros Gerais
      • Configuração de Grupos de Contatos e Usuários
        • Controle de expiração
        • Segurança
      • Metadados
        • Cadastro de Áreas de Negócio
        • Cadastro de Metadados
          • Mapeamento de dados via ligações entre tabelas representadas graficamente
          • Mapeamento de dados via códigos SQL
            • Metadados de Consultas Híbridas
          • Grupos de metadados offline
          • Metadados de Consultas Híbridas
      • Exportação e Importação de BackUp
      • Provedores de Comunicação
    • Criação e Edição de Dashboards
      • Componente Texto
      • Componente Imagem
      • Componente Grafico
      • Componente Cartão
      • Componente Planilha
      • Explorador de Dados
      • Componente Termômetro
      • Componente Mapa
      • Filtro
        • Dados de Metadados
        • Filtro Simples
        • Filtro Intervalo
        • Filtro de Seleção Única
    • Recursos Extras de Dashboards
      • Referências
      • Variáveis de Contexto
      • Escala de Cores
      • Formatação
      • Vínculos automáticos entre componentes
      • Campos Calculados
      • Fórmulas
        • Funções
        • Constantes
        • Operadores
      • Abas
      • Metadados offline associados
    • Cadastro de Tarefas e Alertas
      • Criação de Tarefas e Alertas
      • Enviar E-mail
      • Enviar SMS
      • Exportar Arquivo
      • Executar Store Procedure
      • Abrir e Executar Arquivo
      • Enviar Telegram
      • Enviar WhatsApp
      • Exportar Conteúdo do Sistema
    • Administração
      • Log
        • Logs
      • Painel de Controle
      • Política de Segurança
      • Gerenciar Componentes
      • Gerenciar Exploradores de Dados e Dashboards
      • Conexões
      • Biblioteca de funções
      • Objetos não referênciados
      • Acesso ao menu principal
      • Amazon S3
  • CLIENT WEB
    • Explorador de Dados
    • Detalhamento
    • Cenários
    • WeHelp
    • Interação com Filtros
    • Distribuição de indicadores entre ABAS
    • Acesso e Login
      • Alteração de senha
      • Sair
    • Modo Apresentação de Dashboards
  • Exibir e Ocultar lista de Dashboards
  • Visualização de Dashboards em tela cheia
  • TASK MANAGER
    • Gerenciados de Tarefas
      • Configurações
    • Notificação sobre novas Versões
  • SERVICE
    • Instalação
    • Atualizar versão
    • Atualizar licença
    • Autenticação de duplo fator
    • Definir Fonte de dados
    • Backup
  • Manual de Requisitos
    • Requisitos de Hardware e Software
    • Acesso à Internet - Firewall
    • Arquitetura de Instalação
    • Processador do servidor
    • Balanceamento de carga no servidor Apache
  • Descritivo técnico
    • Resumo da Ferramenta
Fornecido por GitBook
Nesta página
  1. Manual de Requisitos

Processador do servidor

Manual de Requisitos

AnteriorArquitetura de InstalaçãoPróximoBalanceamento de carga no servidor Apache

Neste tópico será apresentada uma sugestão de fórmula matemática para auxiliar na escolha do processador (back-end) (servidor como serviço do Windows, servidor Apache e Gerenciador de Tarefas).

Mas, de qualquer forma, ressaltamos a necessidade de usar uma máquina preparada para um possível upgrade de processador.

Fórmula: N(p) = 2 * K(la) * K(el) * K(ts) * U(max)

Abaixo um exemplo para atender a 300 threads (ou requisições do WK, porque cada requisição cria uma thread) simultâneas (que estão em execução ao mesmo tempo dentro). O resultado foi 16 processadores lógicos (arredondando), o que é atendido por 1 processador (chip físico) de 8 núcleos (cada núcleo dos processadores atuais tem 2 processadores lógicos):

15,42857143 = 2 * 1,428571429 * 0,9 * 0,02 * 300

N(p): Número de processadores lógicos que devemos ter na máquina;

2: Cada núcleo tem 2 processadores lógicos não simétricos. Se eu tenho 2 threads simultâneas, precisarei de 2 núcleos (sendo que cada núcleo tem 2 processadores lógicos) para executar de forma paralela real (sem "time slicing"). Aqui tentamos paralelizar ao máximo as threads (paralelismo real);

K(la): É o coeficiente que considera a média de carga (load average). Considerando ocupar só 70% do total dos processadores lógicos. 30% destinado às tarefas do SO e eventuais outros softwares instalados. Por exemplo, um processador com 2 núcleos e cada núcleo tem 2 processadores lógicos, então podemos executar 4 threads "em paralelo (com time slicing, ou seja, não é paralelismo real)", ocupando assim 100% dos processadores lógicos existentes num determinado momento do tempo. No exemplo acima o valor desse coeficiente é o resultado de: 1/0,7 (que arredondando dá 1.4). Sendo assim, no exemplo acima é adicionado 30% a mais de threads para que se tenha essa margem de sobra de processadores (30% a mais). Ou seja, se a necessidade for de 10 processadores, então multiplicamos por 1.4 para dizer que precisamos de 14 processadores. Logo, 4 processadores ficarão sobrando para o SO e outras coisas. Logo, as threads ocuparão somente 70% da carga total (somente 10 processadores);

K(el): É o "coeficiente efetivo de carga" que considera a carga efetiva do conjunto total de threads existentes simultaneamente (ou seja, quantas threads estarão efetivamente exigindo o esforço do processador em qualquer determinado momento). O servidor do WK que fica no Apache não tem estado, ou seja, uma requisição (que gera uma thread) é criada, processa tudo e é destruída. Considerando somente o servidor do WK que fica no Apache, meu coeficiente pode ser 1 (100%), que significa que uma thread de requisição do WK estará sempre executando e nunca em espera. Mas, no exemplo acima, supondo que somente 90% (0,9 da fórmula) das threads estarão de fato consumindo processador o tempo todo porque tenho as threads geradas pelas conexões do cliente Windows (que são minoria, porque o cliente HTML é o mais usado) ao servidor do WK que roda como um serviço do Windows (estas têm estado, ou seja, uma conexão é feita e fica aberta durante todo o tempo, exigindo processador somente quando há uma requisição de fato). Além disso, existem pontos na execução do código que pode fazer com que qualquer thread entre em modo de espera, por exemplo: Pode ser que algumas estejam aguardando conexão de banco de dados, aguardando resposta de disco, aguardando resposta de rede, aguardando entrada em seção crítica (LOCKs), etc. Para entender mais, esse artigo aqui pode ajudar: https://bitismyth.wordpress.com/2012/03/13/cpu-usage-e-load-average/;

K(ts): Para entender o significado desta parte da fórmula é necessária uma explicação mais longa, que contenha uma pequena introdução a arquitetura de processadores e como o sistema operacional os gerencia. Isso pode ser encontrado nos links mais abaixo. Mas, um bom número que deve atender a todos os casos é 0,02;

U(max): É a quantidade máxima de threads (ou requisições) que se espera que possam existir simultaneamente. Considerando que 1 dashboard que tem 5 indicadores, pode disparar 5 requisições simultâneas.

Links de apoio para melhor entendimento desta fórmula:

https://bitismyth.wordpress.com/2015/04/17/multiplas-aplicacoes-num-mesmo-servidor-ma-ideia/
https://en.wikipedia.org/wiki/Context_switch
https://www.devmedia.com.br/como-funciona-o-sql-server-scheduling/31972
https://sites.google.com/site/proffernandosiqueiraso/aulas/8-gerencia-do-processador
https://www.akitaonrails.com/2019/03/13/akitando-43-concorrencia-e-paralelismo-parte-1-entendendo-back-end-para-iniciantes-parte-3
https://bitismyth.wordpress.com/2012/03/13/cpu-usage-e-load-average/
https://bitismyth.wordpress.com/2015/04/17/multiplas-aplicacoes-num-mesmo-servidor-ma-ideia/
https://bitismyth.wordpress.com/2012/03/06/um-pequeno-teste-com-threads/