2.3 Ajuste do desempenho

O ajuste do desempenho é um assunto complexo. O aplicativo de usuário do Identity Manager depende de diversas tecnologias com várias interações. Não é possível prever todos os cenários de configuração ou de interação do usuário que podem prejudicar o desempenho. Porém, alguns subsistemas estão sujeitos a melhores práticas que incrementam o desempenho. Esse assunto será discutido a seguir.

2.3.1 Registro

O aplicativo de usuário permite o registro por meio do Novell Audit e também da estrutura de código-fonte aberto log4j da Apache. Por padrão, o registro por meio do Novell Audit é desabilitado. Contudo, o registro no arquivo e no console através de log4j é habilitado por padrão.

NOTA:Os tipos de eventos que você pode registrar e a maneira de habilitar ou desabilitar o registro serão abordados no Seção 5.0, Configurando o registro e no Seção 12.0, Configuração de Registro, mais adiante neste guia.

As definições de configuração de log4j estão contidas em um arquivo denominado log4j.xml, em $IDMINSTALL/jboss/server/IDMProv/conf/. Quase no final desse arquivo, você encontrará a seguinte entrada:


<root>     <priority value="INFO" />     <appender-ref ref="CONSOLE" />     <appender-ref ref="FILE" /> </root>

A atribuição de um valor a root garante que qualquer appender de registro que não tenha um nível explicitamente atribuído herde o nível root (nesse caso, INFO). Por exemplo, por padrão, não há um nível de limite atribuído ao appender FILE; portanto, ele assume o nível da raiz (root).

Os níveis de registro possíveis usados por log4j são DEBUG, INFO, WARN, ERROR e FATAL, conforme definido na classe org.apache.log4j.Level. O desempenho poderá ser prejudicado caso essas configurações não sejam utilizadas apropriadamente.

Uma regra útil a seguir é utilizar INFO ou DEBUG apenas ao depurar um problema específico.

Qualquer appender incluído na raiz cujo limite de nível não tenha sido definido deverá ter esse limite especificado como ERROR, WARN ou FATAL, a menos que você esteja depurando algo (como explicado acima).

O desempenho é afetado devido ao alto nível de registro; isso não é decorrente das mensagens verbosas, mas ao fato de que o registro de console e de arquivo em log4j envolve gravações síncronas. Uma classe AsyncAppender está disponível, mas seu uso não garante um melhor desempenho. Os problemas (os quais são conhecidos, sendo problemas do log4j da Apache, e não do Identity Manager) estão documentados em http://logging.apache.org/log4j/docs/api-1.2.8/org/apache/log4j/performance/Logging.html.

O padrão INFO no arquivo de configuração de registro do aplicativo de usuário (acima) é adequado em vários ambientes, mas quando o desempenho for crucial, você deverá considerar a mudança da entrada log4j.xml acima para:

<root> <priority value="ERROR"/> <appender-ref ref="FILE"/> </root>

Em outras palavras, remova CONSOLE e defina o nível do registro como ERROR. Para obter uma configuração de produção totalmente testada/depurada, não é necessário definir o registro no nível INFO, nem deixar o modo de registro CONSOLE habilitado. O ganho em desempenho ao desativá-los pode ser significativo.

Para obter mais informações sobre o log4j, consulte a documentação disponível em http://logging.apache.org/log4j/docs.

Para obter mais informações sobre o uso do Novell Audit com o Identity Manager, consulte o Guia de Administração do Novell Identity Manager.

2.3.2 Cofre de identidade

Consultas LDAP podem causar gargalos em um ambiente de servidor-diretório de uso intenso. Para manter um alto nível de desempenho quando há grande quantidade de objetos, o Novell eDirectory (que forma a base do cofre de identidade no Identity Manager) registra informações solicitadas com freqüência e as armazena em índices. Quando uma consulta complexa é feita em relação a objetos com atributos indexados, o resultado da consulta é obtido de forma muito mais rápida.

O eDirectory é fornecido com os seguintes atributos já indexados:

Nome do Objeto que Originou o Álias cn dc Equivalente a mim extensionInfo Nome GUID ldapAttributeList ldapClassList Member NLS: Common Certificate Obituário Referência Revisão Sobrenome uniqueID uniqueID_SS 

Quando você instala o Identity Manager, o esquema de diretório padrão é estendido com novos tipos de objectclass e novos atributos pertinentes ao aplicativo de usuário. Por padrão, os atributos específicos ao aplicativo de usuário não são indexados. Para a obtenção do melhor desempenho, pode ser útil indexar alguns desses atributos (e talvez também alguns atributos LDAP tradicionais), sobretudo quando o container de usuário contiver mais de 5 mil objetos.

A idéia geral é indexar apenas os atributos que você já sabe que serão consultados com freqüência. (Os atributos podem ser diferentes em ambientes de produção diversos.) O único modo de determinar com certeza que atributos serão usados com freqüência é coletar estatísticas de atributo em tempo de execução. (No entanto, esse processo de coleta pode prejudicar o desempenho.)

O processo de coleta de estatísticas de atributo é abordado em detalhes no eDirectory Administration Guide (Guia de Administração do eDirectory). A indexação também é abordada em detalhes naquele guia. Em geral, você deverá proceder da seguinte forma:

  • Use o Console One para ativar a coleta de estatísticas dos atributos desejados
  • Coloque o sistema em funcionamento
  • Desabilite a coleta de estatísticas e analise os resultados
  • Crie um índice para cada tipo de atributo que possa se beneficiar disso

Se você já sabe que atributos deseja indexar, não precisa usar o Console One. É possível criar e gerenciar índices no iManager por meio de Manutenção > Índices do eDirectory. Por exemplo, se você sabe que os usuários de seu organograma provavelmente realizarão pesquisas com base no atributo isManager, poderá tentar indexar esse atributo para determinar se isso melhora o desempenho.

NOTA:Como melhor prática, é recomendável indexar, no mínimo, os atributos gerente e isManager.

Para obter uma descrição detalhada da indexação de atributos e desempenho, consulte o capítulo “Tuning eDirectory” (Ajustando o eDirectory) no manual Novell’s Guide to Troubleshooting eDirectory (Guia da Novell para Solução de Problemas do eDirectory) de Peter Kuo e Jim Henderson (QUE Books, ISBN 0-7897-3146-0).

Além disso, consulte o capítulo sobre manutenção do Novell eDirectory (que apresenta instruções sobre o ajuste do desempenho) no eDirectory Administration Guide (Guia de Administração do eDirectory) principal.

2.3.3 JVM

A quantidade de memória de pilha alocada para a máquina virtual Java pode prejudicar o desempenho. Se você especificar valores mínimos ou máximos de memória que sejam muito baixos ou muito altos (valores muito altos são os que excedem a memória física do computador), poderá haver um excesso de troca de arquivo de paginação.

Você pode definir o tamanho máximo da JVM do servidor JBoss editando o arquivo run.conf ou run.bat (o primeiro para Linux, o segundo para Windows) em [IDM]/jboss/bin/ em um editor de texto. Aumente “-Xmx” de 128m para 512m, ou mais, se possível. Pode ser necessário experimentar diferentes configurações para determinar o valor ideal para seu ambiente.

NOTA:Há dicas sobre o ajuste do desempenho do JBoss e Tomcat em http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming

2.3.4 Valor de tempo de espera da sessão

O tempo de espera da sessão (o período em que um usuário pode ficar sem interagir com a página em seu browser da Web antes da exibição de uma caixa de diálogo de aviso de tempo de espera da sessão) pode ser mudado no arquivo web.xml presente no arquivo IDM.war. Esse valor deve ser ajustado para corresponder ao ambiente de uso e servidor em que o aplicativo será executado. Em geral, é recomendável que o tempo limite da sessão seja o mais curto possível. Caso os requisitos comerciais possam acomodar um tempo limite de sessão de cinco minutos, isso permitirá que o servidor libere recursos não utilizados duas vezes mais rápido do que ao ser usado um valor de tempo limite de 10 minutos. Assim, o aplicativo Web apresentará melhor desempenho e escalabilidade.

Considere o seguinte ao ajustar o tempo limite da sessão:

  • Um tempo limite de sessão longo pode fazer com que o servidor JBoss fique sem memória, caso muitos usuários efetuem login em um período de tempo curto. Isso pode acontecer com qualquer servidor de aplicativos com muitas sessões simultâneas em andamento.
  • Quando um usuário efetua login no aplicativo de usuário, uma conexão LDAP é criada para esse usuário e vinculada à sessão. Assim, quanto mais sessões estiverem em andamento, maior será o número de conexões LDAP utilizadas. Quanto mais longo o tempo de espera de sessão, maior o tempo durante o qual essas conexões ficam abertas. Um grande número de conexões ao servidor LDAP (mesmo que inativas) pode prejudicar o desempenho do sistema.
  • Se o servidor começar a apresentar erros de memória insuficiente, e se os parâmetros de ajuste da coleta de lixo e pilha da JVM já tiverem os melhores ajustes para os ambientes de uso e servidor, convém considerar a redução do tempo limite de sessão.

Para ajustar o valor de tempo limite da sessão, você deverá abrir o arquivamento IDM.war , localizar o arquivo web.xml nele contido e editar a seguinte seção do arquivo (principalmente o valor numérico, aqui mostrado como 20, que significa 20 minutos, o padrão):

<session-config>     <session-timeout>20</session-timeout> </session-config>

Em seguida, grave o arquivo e o arquivamento e reinicie o servidor.

NOTA:A edição manual de arquivos em arquivamentos Web deverá ser feita por uma pessoa com experiência em desenvolvimento e distribuição de aplicativos Web Java.