Sobre Resultados de Desempenho
O sistema usado para os testes é um cluster esticado do Oracle Fusion Middleware (FMW) configurado nas regiões do Oracle Cloud Infrastructure (OCI) de Frankfurt e Amsterdã.
O domínio WebLogic consiste em 5 nós distribuídos em diferentes locais para permitir comparações de desempenho de várias topologias: servidores em execução no mesmo domínio de disponibilidade que o banco de dados, servidores na mesma região, mas em diferentes domínios de disponibilidade e servidores localizados em outra região.
Esses testes de esforço foram executados usando a Demonstração de Ordem do SOA Fusion (FOD) como um aplicativo SOA de amostra. A demonstração do FOD foi modificada para inserir mensagens do Java Message Service (JMS) em um destino de Destino Distribuído Uniforme (UDD) quando uma ordem é concluída. Este exemplo usa muitos bancos de dados e vários adaptadores SOA, como o Adaptador de Arquivos e o Adaptador JMS. Ele também envolve diferentes componentes SOA, como Mediator, BPEL (Business Process Execution Language), mecanismo de regras e vários recursos WebLogic.
O diagrama a seguir mostra o ambiente de cluster esticado FMW usado para os testes:
fmw-esticado-desempenho-env-oracle.zip
Os valores reais de latência entre as redes nesse ambiente eram:
| Entre Hosts | Latência média (RTT em ms) |
|---|---|
| No mesmo domínio da disponibilidade | 0,3 |
| Na mesma região, mas em um domínio de disponibilidade diferente | 0,6 |
| Em diferentes regiões (Frankfurt e Amesterdão) | 6.5 |
Revisar Testes de Estresse
Algumas das configurações testadas foram:
- Estressando o cluster com dois nós, aplicando diferentes latências entre os servidores e entre um dos servidores para o banco de dados.
- Teste de esforço de servidores individuais, cada um com diferentes latências para o banco de dados.
- Executar testes com ambos os servidores colocados com o banco de dados (somente local) e com ambos os servidores localizados remotamente a partir do banco de dados (somente remoto).
- Estressando o cluster com dois nós ativos em cada região.
Para cada configuração, diferentes cargas de trabalho foram testadas. Todas as solicitações de carga de trabalho são enviadas primeiro para o front-end, onde são distribuídas (por meio do balanceamento de carga global, depois dos balanceadores de carga locais e, em seguida, dos servidores Web) entre as instâncias do Oracle WebLogic Server. A categoria de carga de trabalho (baixa, média, alta) depende do número de nós ativos em cada definição e é limitada pelos limites de simultaneidade do banco de dados. Por exemplo, 80 usuários virtuais simultâneos seriam considerados uma baixa carga de trabalho para servidores WebLogic se houver quatro nós em execução, mas uma alta carga de trabalho se apenas um nó estiver ativo. No entanto, da perspectiva do banco de dados, a carga de trabalho permanece a mesma. Para simplificar, as cargas de trabalho usadas são as seguintes:
- Cargas de trabalho baixas (20 usuários virtuais simultâneos por servidor WebLogic, com um máximo de 40 usuários virtuais simultâneos no sistema)
- Cargas de trabalho médias (40-60 usuários virtuais simultâneos por servidor WebLogic, com um máximo de 120 usuários virtuais simultâneos no sistema)
- Cargas de trabalho elevadas (80 utilizadores virtuais simultâneos por servidor WebLogic, com um máximo de 160 utilizadores virtuais simultâneos no sistema)
Com base nos resultados do teste de esforço, estas são as conclusões:
- Desempenho geral do cluster
O desempenho geral do cluster (em termos de throughput de WebLogic, transações por segundo (TX/seg)) para um cluster com 2 servidores:
- Quando ambos os servidores estão no mesmo Domínio de Disponibilidade (AD) (tomado como referência): 100%
- Quando cada servidor está em um AD diferente: ~100%
- Quando um servidor está em uma região diferente (6.5ms tempo de ida e volta (RTT)): 90-95%
- Quando ambos os servidores estão em uma região diferente do BD (6.5ms RTT): 85-95%
- Desempenho por servidor
O desempenho por servidor (em termos de throughput de WebLogic, TX/seg):
- Para o servidor no mesmo AD que DB (tomado como referência): 100%
- Para o servidor no outro AD: 98-99%
- Para o servidor na outra região: 85-90%
- Número de conexões de origem de dados ativas
O número de conexões de origem de dados ativas aumenta com maior latência para o banco de dados. Embora dependa da carga de trabalho, o servidor na região 2 mostra até 2x conexões ativas do que o servidor colocado no Banco de Dados. Considere isso para um dimensionamento correto das origens de dados e sessões de banco de dados WebLogic.
- Transações JTA
As transações JTA permanecem ativas por períodos mais longos em servidores com maior latência para o banco de dados. Transações que permanecem ativas por períodos mais longos têm maior probabilidade de serem afetadas por falhas. Portanto, torna-se particularmente importante nesses sistemas que os logs de transação usem armazenamentos persistentes JDBC. Para falhas do servidor, a migração do serviço deve ocorrer e a recuperação ocorrerá automaticamente.
- Latência entre regiões
Para obter uma latência entre regiões do 6.5ms RTT e implementar as melhores práticas fornecidas por este documento para os clusters FMW Esticados:
- Há baixa degradação de desempenho usando um cluster esticado (~10%).
- Há uma degradação de desempenho semelhante para um cluster com um servidor em cada região e um cluster com ambos os servidores na região remota. Isso ocorre porque a comunicação intra-cluster também é afetada pela latência.
- Latência entre ADs
A latência entre ADs (0.6ms) não tem um impacto significativo no desempenho geral de um sistema SOA FOD.
Observação:
Com tudo isso em mente e com as penalidades de desempenho observadas em muitos testes, a Oracle não suporta clusters estendidos do Oracle Fusion Middleware que excedem 10 milissegundos de latência (RTT) entre os sites. Os sistemas podem operar sem problemas, mas os tempos de transação aumentarão consideravelmente. Latências além de 10 milissegundos (RTT) também causarão problemas no cluster do Oracle Coherence usado para implantação e JT, web services ou timeouts de aplicativos. Isso torna as soluções apresentadas neste playbook adequadas principalmente para sites ou regiões com baixa latência entre eles.
Ao pressionar um cluster com 2 nós, o gráfico a seguir mostra o desempenho geral do cluster, dependendo de onde os servidores estão localizados. A referência (100%) é quando ambos os servidores são executados no mesmo AD que o banco de dados.
Ao pressionar um cluster com 2 nós, o gráfico a seguir mostra o desempenho do servidor que não está colocado no banco de dados (ele está no outro AD ou em uma região remota) em comparação com o desempenho do servidor que está colocado no banco de dados:
Ao estressar um cluster com 2 nós, esses gráficos mostram o número de conexões de origem de dados ativas (média) para cada servidor. Um servidor é sempre colocado no banco de dados (site1) e o outro está em valores de latência diferentes do banco de dados (site2):
Ao estressar um único servidor com diferentes latências de banco de dados, os seguintes resultados de desempenho são observados, em comparação com um servidor que está co-localizado com o banco de dados, sob carga média a alta. A referência (100%) é quando o servidor está no mesmo AD que o banco de dados.
Ao estressar um único servidor com diferentes latências para o banco de dados, estas são as conexões de origem de dados ativas sob estresse médio a alto:
Ao estressar um único servidor com diferentes latências para o banco de dados, a seguinte imagem mostra o tempo médio de JTA ativo para diferentes latências para o banco de dados:
Ao comparar o desempenho de um cluster com ambos os servidores na mesma região que o banco de dados (somente local) vs. um cluster com ambos os servidores em uma região diferente do banco de dados (somente remoto), os seguintes resultados de desempenho são observados. A referência (100%) é o cluster somente local.
A figura a seguir mostra o tempo médio de atividade de JTA TX para um cluster com ambos os servidores sendo executados na mesma região do banco de dados (somente local) e um cluster executando ambos os servidores em uma região diferente da do banco de dados (somente remoto).
Revisar Horas Iniciais
Diferentes atrasos são esperados de acordo com as configurações de capacidade inicial nas origens de dados. Por padrão, a maioria das origens de dados do Oracle Fusion Middleware (FMW) usa uma capacidade inicial zero para seu pool de conexões. No entanto, para reduzir o tempo de resposta do sistema durante a operação normal de tempo de execução, pode ser benéfico aumentar a capacidade inicial do pool. No entanto, em um cluster esticado, os servidores que residem remotamente no Banco de Dados mostrarão maior latência no início à medida que for usada uma capacidade de pool inicial mais alta.
É necessária uma decisão equilibrada entre a otimização dos tempos de resposta durante a operação normal e a minimização do tempo de início para determinar as configurações ideais de capacidade inicial. Como a capacidade inicial é configurada no nível da origem de dados (pool de conexões), essas configurações influenciam o tempo de inicialização de todos os servidores do cluster (os locais do banco de dados e os remotos).
O gráfico a seguir mostra os horários de início do servidor WebLogic à medida que a latência para o banco de dados aumenta, para diferentes valores de tamanho inicial em todas as origens de dados (11 origens de dados no total):
Revisar Tempos de Migração do Serviço JMS
No entanto, o tempo gasto para uma operação de migração de serviço da região 1 para a região 2 pode aumentar devido à latência para o banco de dados. Esse aumento é causado pelo tempo gasto na recuperação das mensagens no outro servidor, porque elas são lidas do armazenamento persistente no banco de dados na outra região.
O incremento será maior se os armazenamentos persistentes tiverem um grande número de mensagens pendentes. Para mensagens JMS com um tamanho de 2,7 KB cada, a imagem a seguir mostra os tempos de migração do serviço JMS quando um dos armazenamentos persistentes tem um alto número de mensagens pendentes (cerca de 8000) e o serviço migra de um servidor colocado no banco de dados para outro servidor, para diferentes latências entre o servidor de destino e o banco de dados:
A imagem a seguir mostra o incremento de tempo de migração de serviço (%) com um alto número de mensagens pendentes (cerca de 8000) para diferentes latências entre o servidor de destino e o banco de dados. A referência (100%) é quando o serviço migra para um servidor que está no mesmo Domínio de Disponibilidade (AD) que o banco de dados.
A imagem a seguir mostra os tempos de migração para o mesmo caso, mas com um número baixo de mensagens pendentes (cerca de 50) para diferentes latências entre o servidor de destino e o banco de dados.
A imagem a seguir mostra o incremento (%) do tempo de migração do serviço JMS com um número baixo de mensagens pendentes (cerca de 50) para diferentes latências entre o servidor de destino e o banco de dados. A referência (100%) é quando o serviço migra para um servidor que está no mesmo AD que o banco de dados.
Revisar Tempos de Implantação do Composto SOA
Ao implantar um composto (implantando sua primeira versão ou atualizando para uma versão mais recente), o composto pode ser implantado mais cedo nos servidores da região 1 do que nos servidores da região 2, embora não seja formalmente ativado até que esteja disponível em todos os membros do cluster.
A imagem a seguir mostra o aumento no tempo necessário para carregar um composto em um servidor durante a inicialização do servidor, com latência para o banco de dados em comparação com o tempo necessário para carregá-lo em um servidor que reside no mesmo Domínio de Disponibilidade (AD) que o banco de dados. O tamanho do composto é de 365 KB.
A imagem a seguir mostra o aumento no tempo necessário para implantar um composto com os comandos da Oracle WebLogic Scripting Tool (WLST), para diferentes latências do servidor que executa a implantação no banco de dados.
Verificar Tráfego Entre Sites
Esse isolamento, no entanto, é não determinístico (por exemplo, há espaço para cenários de failover em que uma chamada do Java Message Service (JMS) pode ocorrer nos dois sites). Dito isto, para um aplicativo típico, a maior parte do tráfego ocorre entre as instâncias do Oracle WebLogic Server e o banco de dados. Esta será a chave para o desempenho da topologia de clusters estendidos do Oracle Fusion Middleware (FMW). Esta imagem mostra o percentual de tráfego entre um servidor WebLogic na região 2 e os diferentes endereços na região 1 durante um teste de estresse. Note que mais de 90% do tráfego acontece entre o servidor e o banco de dados, que está localizado na região 1.
Para capturar a quantidade de tráfego por IP entre os sites, você pode usar a ferramenta iftop. Por exemplo:
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900A imagem a seguir mostra o percentual de tráfego entre um servidor WebLogic na região 2 e os diferentes endereços na região 1 durante um teste de estresse.
