Parâmetros de Cache do Configurador de Produtos

Os parâmetros de cache do Siebel Product Configurator são fundamentais para performance e escalabilidade de ambientes Siebel que utilizam Order Manager.

Percebam que falo de adequação dos parâmetros e não do cálculo para determinar os mesmos, pois todo o esforço necessário para mensurar as variáveis necessárias para o correto ajuste dos ambiente é complexo e varia de caso a caso ou de ambiente Siebel para ambiente Siebel.

Objetivos – Adequar Parâmetros de Cache do Configurador de Produtos

A preocupação desse artigo é fornecer meios e conhecimento suficientes para que o Administrador de Produtos ou o Siebel Administrator consiga apenas adequar os principais parâmetros de cache do configurador de produtos relacionados ao motor do Configurador de Produtos e não determinar os melhores valores para um setting inicial. Portanto, parto da premissa que o trabalho e esforço decorrente do setting inicial já foi despendido em algum momento.

Antes de ganho de performance ou escalabilidade em si, os ajustes visam garantir que cada Object Manager acumulará memória até um limite gerenciável pelo Sistema Operacional e que o consumo máximo de memória previsto para um servidor não comprometa o desempenho geral do ambiente Siebel.

Continua após publicidade.

Caso II – Cenário hipotético base

Para fins meramente didáticos, vamos considerar o seguinte setting de um Application Object Manager/AOM (eProdCfgObjMgr, eCommunicationsObjMgr, EAIObjMgr, eSales, etc.), como exemplo:

• Cada produto ficará em cache em cada Object Manager (OM) do AOM: 13 produtos * 15MB = 195MB
• Cada worker ficará em cache em cada OM do AOM: 50 workers * 4MB = 200MB
• Cada OM do AOM já inicia no SO com =~190MB
• Cada usuário logado no OM acrescenta um overload de =~3MB ao OM

Nesse ponto, se o servidor estiver com carga máxima, cada OM terá 20 tarefas running, consumido aproximadamente:

195MB para os produtos + 200MB para os workers + 190MB inicial + 60MB de usuários logados = 645 MB

Como o AOM utiliza até 12 OMs nessa configuração:

12 * 645 = 7740 MB de consumo só pro AOM fazendo caching de produtos complexos.

Se somarmos a memória utilizada pelos outros processos do Sistema Operacional teríamos:

6000 + 7740= 13740MB

Com carga máxima do servidor, considerando que estivesse dedicado ao AOM, já estaríamos consumindo cerca de 85,8% da capacidade de memória de um server de 16GB, ou seja, bem próximo a capacidade máximo do servidor.

As alterações mais comuns num ambiente produtivo de Siebel CRM são relacionados ao produtos complexos. Novos produtos podem ser criados, produtos podem ser desativados, novas configurações podem ser disponibilizadas, etc.

Qualquer variação abrupta no tamanho dos produtos estimados no setting inicial exigirá perícia na adaptação dos parâmetros para evitar crashs, consumo exagerado de memória ou outros efeitos colaterais.

Caso II – Aumento da complexidade do produtos

Imagine que a média de tamanho dos produtos e workers passasse de 15MB para 30MB e de 4MB para 15MB, respectivamente, e sem nenhuma adequação nos parâmetros recomendados nesse relatório:

(13 * 30) + (50 * 15) + 190 + (20*3)

390MB para os produtos + 750MB para os workers + 190MB inicial + 60MB de usuários logados= 1390MB

1390 * 12 = 16680MB

Ou seja, o servidor iria chegar a 100% de memória física antes de ter atingir a quantidade máxima de usuários logados.

Caso III – Aumento da quantidade de produtos

Uma outra alteração de paradigma de uso da aplicação que tende a causar um mau gerenciamento de recursos seria se, ao invés de aumentar o tamanho dos produtos atuais, resolvesse se criar novos produtos. Não que essa decisão seja errada, apenas é um cenário que não foi contemplado no setting inicial. Suponha que:

Tenhamos 30 produtos, com média de 15MB de factory, 4MB de worker cada e nenhum ajuste foi feito nos parâmetros do AOM.

Nesse caso, somente 13 produtos ficariam simultaneamente no cache, ou seja, sempre que uma tarefa fosse balanceada para um OM que não tem o produto solicitado já carregado, o OM teria o overhead de remover o produto que está com maior tempo de inatividade do cache e carregar o produto recém instanciado. Em larga escala, esse tipo de overhead pode ser significativo e causar lentidão nas atividades de configuração de produto.

Obviamente não haveria problema de sobre-alocação de memória, pois os parâmetros de factories e workers, que não foram alterados, limitariam a sobrecarga. Ainda assim, o uso de recursos do cache não estaria adequado.

Caso IV – Menos usuários que o previsto

Uma outro problema de natureza menos grave mas que, ainda assim, exigiria algum esforço de adequação para melhor aproveitamento de recursos seria se, em algum momento, a quantidade de usuários logados por servidor fosse muito menor que a quantidade estimada pra carga atual.

Imagine que, ao invés de 240 usuários logados (tarefas máxima), temos apenas 60 usuários e nenhum parâmetro foi alterado.

Nessa situação não teremos nenhum overload de recursos, muito pelo contrário. A carga seria mais baixa que a capacidade de infra suportaria.

Em si, tirando o desperdício de recursos de hardware empregados numa situação que poderia ser atendida por servidores bem “menores”, teríamos um problema de granularidade de cache de produtos. Como o cache de um produto é feito por OM, quanto menos usuários trabalhando com o Configurador de Produtos, menor a chance de um produto complexo já estar em cache num determinado OM.

Pra essa situação não faremos nenhuma inferência, pois sua adequação exigiria passarmos por várias análises para determinar os melhores valores para Min/MaxMthreads e MaxTasks e esse esforço não pode ser traduzido em poucas linhas.

Conclusão

Em resumo, alterações no tamanho final dos produtos ou na quantidade de produtos, mesmo que pequenas, podem e devem exigir alteração dos parâmetros relacionados ao cache de produtos complexos dos AOM assim como outros fatores que influenciam diretamente a quantidade de memória máxima que um OM pode alocar pra si sem comprometer o ambiente e causar indisponibilidade.

Se sua empresa estiver enfrentando problemas de performance ou crashs decorrentes de configuração inadequada dos parâmetros relacionados ao configurador de produtos, conte com a Troubleshooter IT para ajudá-los a identificar melhorias.

Abraço,