Sobre a carga de trabalho FileNet

Ao lidar com acidentes de automóvel, um cliente envia sua solicitação à sua seguradora. Geralmente um analista de sinistros é designado para investigar a solicitação. O cliente geralmente recebe uma ligação, carta ou email do analista se apresentando e informando ao cliente do processo geral que a empresa segue. O analista então analisa a política do cliente para verificar que cobertura e franquia ele tem, e avalia o tipo e extensão dos danos e/ou ferimentos resultados do acidente (fotos também serão tiradas). Na maioria dos casos, o analista pode simplesmente pedir que o cliente estime o custo de reparo do carro e pagá-lo a quantia final. O resultado final é que se escreve um cheque para as partes apropriadas. Então o caso é fechado.

Em todas estas etapas, atualizações são feitas em um sistema de gerenciamento de conteúdo FileNet—registros são criados e atualizados, e fotos são transferidas por upload e marcadas para cada solicitação à medida que o processo avança.

A carga de trabalho usada neste artigo simula o cenário acima. A carga consiste em um driver de teste Java™ cliente implementando as APIs do FileNet Content Engine. Ela suporta sessões de usuário simultâneas. Também pode ser executada em máquinas clientes separadas, todas dirigindo a carga para um único back end FileNet. O back end consiste de múltiplas instâncias de servidores de aplicativos FileNet Content Engine. Todos os servidores Content Engine se conectam aos bancos de dados DB2 9.7 que servem de repositório de metadados para os documentos da solicitação.

A composição da carga de trabalho é a seguinte:

• 10% - Criar documentos de solicitação
• 45% - Modificar / anotar documentos de solicitação
• 10% - Navegar por todas as solicitações
• 15% - Procurar solicitações
• 20% - Recuperar documentos de solicitação

A Figura 1 ilustra a topologia de teste:

A Tabela 1 lista os detalhes dos níveis de hardware e software usados neste estudo:

Voltar para parte superior

ORB e as APIs FileNet

FileNet Content Engine oferece dois tipos de APIs:

• API Java 4.0 que usa transporte EJB (RMI/IIOP para WebSphere)
• Web Services Interface (WSI) que usa transporte HTTP

Ambos os transportes são suportados no código cliente jace.jar do Content Engine. Como aplicativo cliente, o driver de teste usa as APIs Java e, portanto, usa o transporte EJB.

WebSphere suporta transporte EJB usando Object Request Broker (ORB). O ORB é usado para gerenciar comunicações entre aplicativos clientes (neste caso, o driver de teste escrito em Java) e aplicativos do servidor (neste caso, servidor de aplicativos FileNet Content Engine), bem como entre os próprios componentes WebSphere.

O ORB gerencia pedidos de entrada e saída para objetos de tecnologia Java remotos, como componentes EJB. ORB proporciona uma estrutura para clientes localizarem EJBs no servidor e invocarem operações neles como se fossem locais. Estes pedidos são feitos usando mensagens. Mensagens podem ser grandes ou pequenas, dependendo da carga de trabalho. Uma carga de trabalho mais complexa, como o cenário de seguros deste artigo, requer ajuste fino de mensagens ORB. O tamanho padrão de fragmento ORB pode servir bem para várias cargas de trabalho, mas um tamanho de mensagem de ORB ajustado pode impulsionar o desempenho em conjunto com ajuste de bancos de dados e outros ajustes no WebSphere, bem como tamanho de conjunto de conexões JDBC e conjunto de encadeamentos da Web.

Algumas cargas de trabalho sendo executadas em um ambiente FileNet Content Engine podem apresentar um interessante padrão no uso de recursos: não há gargalo de E/S de disco, nem limitação de memória nem problemas de desempenho de driver, mas ainda assim os CPUs são subutilizados. Por exemplo, no cenário de seguros, antes do ajuste fino no fragmento ORB, a utilização máxima de CPU conseguida é de cerca de 55%, como mostrado na Figura 2:

Este artigo foca no rastreamento e ajuste das mensagens ORB no servidor de aplicativos FileNet Content Engine de modo a aumentar a utilização de CPU.

Voltar para parte superior

Ligue o rastreio ORB no WebSphere

Para ativar o rastreio ORB no Websphere, siga as etapas abaixo.

1. No Console Administrativo do WebSphere, navegue para Application servers > server1 > Container Services > ORB \ service.
2. Nesta página de propriedades, selecione a caixa de opção ORB Tracing para ativar o rastreio ORB. Também é possível visualizar propriedades gerais de ORB como Request timeout, Request retries count e outras na mesma página.
3. Para definir o nível de rastreio PMI apropriado, navegue até Troubleshooting > Logs and Trace > server1 > Diagnostic trace service > Change log detail levels.
4. Clique no ORBRas e selecione All Messages and Traces. A caixa de configuração deve mostrar uma entrada semelhante a *=info: ORBRas=all. Aqui é possível ativar outros rastreios, se quiser.

   Use níveis de registro para controlar quais eventos são processados pelos logs de Java Clique em Components para especificar um nível de detalhe de log para componentes individuais, ou clique em Groups para especificar um nível de detalhe de log para um grupo pré-definido de componentes. Clique no nome de um componente ou grupo para selecionar um nível de detalhe de log. Níveis de detalhe de log são acumulativos; um nível próximo do topo da lista inclui todos os níveis subsequentes.

5. Lembre-se de desativar o rastreio alterando a configuração de volta para No Logging após a resolução de problemas.

   Não há necessidade de reiniciar o servidor de aplicativos se você estiver usando WebSphere V6.1 ou posterior. Normalmente um arquivo de rastreio pode ser encontrado em /usr/IBM/WebSphere61ND/AppServer1/profiles/AppSrv01/logs/server1/trace_xxx.log.

Voltar para parte superior

Analise rastreios ORB

Quando o rastreio estiver ativado, será feito log de várias entradas. É possível diminuir sua carga de trabalho reduzindo o número de usuários e a duração das execuções. A chave é poder conseguir amostras suficientes (em torno de 10 transações neste caso) para que uma boa cobertura seja possível em termos de pedidos ORB. A Listagem 1 exibe uma amostra da saída de rastreio ORB:

11/2/09 11:40:40:671 PST] 00000040 ORBRas 3 com.ibm.rmi.ras.Trace dump:81 RT=2:
P=364261:O=0:WSTCPTransportConnection

[addr=10.0.1.68,port=41312,local=56772] 
IN COMING:
Fragment Message
Date:          November 2, 2009 11:40:40 AM PST
Thread Info:   RT=2:P=364261:O=0:WSTCPTransportConnection[addr=10.0.1.68,
		port=41312,local=56772]
Local Port:    56772 (0xDDC4)
Local IP:      10.0.1.238
Remote Port:   41312 (0xA160)
Remote IP:     10.0.1.68
GIOP Version:  1.2
Byte order:    big endian
Fragment to follow: Yes

Message size:  1012 (0x3F4)
--
Request ID:        1219


0000: 47494F50 01020207 000003F4 000004C3   GIOP............
0010: 2E20546F 206C6175 6768696E 6720636C   . To laughing cl
0020: 65616E20 41727468 75722066 69727374   ean Arthur first
0030: 206F7220 6F6E2069 6E207468 65736520    or on in these 
0040: 74686520 6D656469 63616C20 73757370   the medical susp
0050: 656E6465 642E2041 6E206C69 6B652069   ended. An like i
0060: 74206120 66696C6D 20467261 6E636520   t a film France 
0070: 77696C6C 2E205468 6520646F 70616E74   will. The dopant
0080: 2077616E 74206174 206C6F72 64206F66    want at lord of
0090: 20696E20 62757420 70617274 69636970    in but particip
00A0: 6174696F 6E20696E 746F2064 75652062   ation into due b
00B0: 65696E67 20616E64 2E204672 6F6D2066   eing and. From f

.........
IN COMING:
Fragment Message
Date:          November 2, 2009 11:40:41 AM PST
Thread Info:   RT=2:P=364261:O=0:WSTCPTransportConnection[addr=10.0.1.68,
		port=41312,local=56772]
Local Port:    56772 (0xDDC4)
Local IP:      10.0.1.238
Remote Port:   41312 (0xA160)
Remote IP:     10.0.1.68
GIOP Version:  1.2
Byte order:    big endian
Fragment to follow: No 
  
Message size:  160 (0xA0)
--
Request ID:        1219

Na listagem acima, Request ID: 1219 tem vários fragmentos em uma mensagem. É fácil determinar quantos fragmentos existem no pedido executando um comando grep (UNIX) ou find (Windows). Por exemplo:

c:\>find "Request ID:        1219" trace_09.11.02_11.40.43.log

---------- TRACE_09.11.02_11.40.43.LOG
Request ID:        1219
Request ID:        1219
Request ID:        1219
Request ID:        1219
Request ID:        1219
Request ID:        1219

Como resultado, o pedido com ID 1219 tem seis fragmentos—cinco fragmentos têm 1012 bytes e um fragmento tem 160 bytes. Vamos examinar outro pedido (veja a Listagem 3):

Fragment Message
Date:          November 2, 2009 11:40:41 AM PST
Thread Info:   ORB.thread.pool : 0
Local Port:    56772 (0xDDC4)
Local IP:      10.0.1.238
Remote Port:   41312 (0xA160)
Remote IP:     10.0.1.68
GIOP Version:  1.2
Byte order:    big endian
Fragment to follow: Yes
Message size:  1012 (0x3F4)
--
Request ID:        1154


0000: 47494F50 01020207 000003F4 00000482   GIOP............
0010: FFFFFFFD 00000001 00BDBDBD 7FFFFF0A   ...............
0020: FFFFFFFF FFFE21C4 00000014 00000010   ......!.........
0030: 00000000 51003010 00030000 00012315   ....Q.0.......#.
0040: FFFFFFFD 00000065 00BDBDBD FFFFFFFF   .......e........
0050: FFFE3878 00010002 00BDBDBD FFFFFFFF   ..8x............
0060: FFFE3930 00BDBDBD 00130008 00BDBDBD   ..90............
0070: FFFFFFFF FFFE3964 00110006 00BDBDBD   ......9d........
0080: FFFFFFFF FFFE39A4 00010006 00BDBDBD   ......9.........
0090: FFFFFFFF FFFE39D0 00000001 00010005   ......9.........
00A0: 00BDBDBD FFFFFFFF FFFE3A08 00BDBDBD   ..........:.....
00B0: 7FFFFF0A FFFFFFFF FFFE2130 00000014   .........!0....

......
		

Uma análise similar mostra que o ID do Pedido 1154 tem 117 ocorrências. Com 1012 bytes para cada fragmento, este pedido tinha um tamanho de mensagem de 118.170 bytes (117 x 1012). Mensagens ORB são enviadas de maneira serial, tornando este bloqueio de pedidos na conexão ORB mais longa que pedidos mais curtos. Sob uma carga pesada, isto pode contribuir para enfileiramento na comunicação ORB entre o cliente Java e os aplicativos FileNet WebSphere, e esta foi a causa dos CPUs subutilizados (como os resultados mostrarão mais tarde).

Voltar para parte superior

Ajuste o tamanho do fragmento ORB

Como a análise acima mostra, o tamanho do fragmento ORB determina quantos fragmentos em um pedido precisam ser enviados na conexão ORB. Quanto mais fragmentos houver em uma mensagem, por mais tempo a conexão ORB será necessária. Um balanço entre o tamanho do fragmento e a duração de um pedido médio pode impulsionar o desempenho. Certamente, se todos os pedidos em uma carga de trabalho fossem uniformes quanto ao tamanho, seria fácil definir o tamanho do fragmento. Geralmente uma carga de trabalho é mais complexa, como no cenário de seguros, no qual transações de criação, atualização, procura, navegação e recuperação estão juntas, e a carga de trabalho é executada sob usuários simultâneos. O tamanho dos documentos também pode variar.

Mas como é possível determinar o melhor tamanho para o fragmento ORB?

É possível usar a abordagem de determinar um tamanho de mensagem médio. Ao executar a carga de trabalho por um período razoável de tempo—uma hora—, nós coletamos um grande número de rastreios ORB. Esta abordagem de "horário de pico" não apenas cobriu documentos de diversos tamanhos, mas também garantiu que as transações fossem bem representadas nesta duração. Ao analisar os rastreios ORB, descobrimos que o maior tamanho de mensagem é 120 KB, o menor, 6 KB e o médio, 40 KB. A distribuição mostra que a maioria das mensagens ORB está entre 30 K e 48 K. Isto nos diz que nosso Tamanho de Fragmento ORB inicial de 1012 era pequeno demais e que isto causou a criação de um grande número de fragmentos, que causaram gargalo na conexão ORB.

Há dois lugares em que está variável deve ser definida: servidor e cliente. No servidor, é possível especificar novos valores para as propriedades customizadas de ORB no console administrativo. Quaisquer valores especificados por você terão precedência sobre valores padrão do JDK ou do WebSphere Application Server para estas propriedades. As configurações customizadas de ORB especificadas no console administrativo são armazenadas no arquivo do sistema server.xml do WebSphere Application Server e são passadas para um ORB em um objeto de propriedades sempre que um ORB for inicializado. Para usar o console administrativo para definir propriedades customizadas de ORB: no console administrativo, clique em Application Servers > Application Servers > serverName > ORB Service > Custom Properties. Defina uma propriedade customizada com o nome com.ibm.CORBA.FragmentSize e o valor desejado. Em nosso caso, nós a definimos em 40 K, que foi o tamanho médio da maioria das mensagens ORB. As especificações seguintes são para com.ibm.CORBA.FragmentSize:

• Unidades: Bytes
• Padrão: 1024
• Faixa: De 64 até o maior valor de tipo de número inteiro Java que seja divisível por 8

Este parâmetro também deve ser definido no lado do cliente com uma propriedade de sistema -D, caso um aplicativo Java independente esteja sendo usado. Nós incluímos em nosso driver de teste Java -Dcom.ibm.CORBA.FragmentSize=40000.

Voltar para parte superior

Resultados: Antes e depois

O número reduzido de fragmentos ORB, por sua vez, reduziu a contenção na conexão ORB. Isto é refletido na diferença no uso de CPU. As Figuras 3 e 4 abaixo mostram as telas antes e depois:

Voltar para parte superior

Outras sugestões de ajustes

Windows® Server 2008 R2

No ambiente de desempenho, o servidor de aplicativos FileNet e o servidor de banco de dados residem em servidores de núcleos múltiplos e soquetes múltiplos. Ambos os servidores executam Microsoft Windows Server 2008 R2. Windows Server 2008 R2 vem com alguns novos recursos que têm impacto no desempenho. No mínimo, recomenda-se avaliar as seguintes áreas:

• Função do servidor - selecione os recursos pré-alocados apropriados para a função (por exemplo, Servidor de Diretórios em vez de Servidor de Aplicativos)
• Núcleo de servidor - Use núcleo de servidor se possível; OS sem UI para aumentar o desempenho e melhorar a segurança
• WSRM (Windows System Resource Manager) - Use WSRM para gerenciar recursos alocados a aplicativos
• Melhorias de rede integradas em relação a versões anteriores do Windows
• Armazenamento em cache de gravação de disco - melhoria substancial no desempenho de armazenamento
• Gerenciamento de energia - suspensão de processador inativo para economizar no consumo de energia

Configurações de Registro do DB2 9.7 integradas no FileNet

Há vários parâmetros de desempenho úteis que são integrados no mecanismo DB2 para aplicativos FileNet. Todos eles podem ser automaticamente definidos com a variável de registro DB2_WORKLOAD configurada para FILENET_CM. Estes são o comando em si e a saída:

%> db2set DB2_WORKLOAD=FILENET_CM

%> db2set

DB2_WORKLOAD=FILENET_CM
DB2_SKIPINSERTED=YES [DB2_WORKLOAD]
DB2_USE_ALTERNATE_PAGE_CLEANING=YES [DB2_WORKLOAD]
DB2_EVALUNCOMMITTED=YES [DB2_WORKLOAD]

DB2 9.7 autoconfigure

DB2 9 tem o recurso de configuração automática, que pode simplificar o ajuste em bancos de dados para uma carga de trabalho particular. O recurso calcula e exibe valores iniciais para o tamanho do buffer pool, configuração de banco de dados e parâmetros de configuração do gerenciador de banco de dados, com a opção de aplicar estes valores recomendados. Por exemplo, é possível especificar workload_type como simples, misto ou complexo. O DB2 automaticamente ajustará o tamanho do buffer pool e as alocações de memória. Ele leva em conta que cargas de trabalho simples costumam usar E/S intensamente e ser constituídas, na maior parte, de transações; enquanto cargas de trabalho complexas costumam usar o CPU intensamente e ser constituídas, na maior parte, de consultas. O seguinte fragmento de código é um exemplo da execução de autoconfigure após um banco de dados ser criado:

db2 autoconfigure using mem_percent 95 workload_type mixed tpm 45000 admin_priority \
performance apply DB only

Ajuste do WebSphere

Outros parâmetros de ajuste do WebSphere a se considerar para cargas de trabalho do FileNet:

• Tamanho aumentado do conjunto de encadeamentos de objetos EJB no WebSphere
• Tamanho aumentado do conjunto de conexões JDBC no WebSphere
• Tamanho de heap de JVM aumentado
• Chamadas RC4 e MD5 desativadas no WebSphere
• JVMs do Content Engine adicionais criadas para reduzir contenções de bloqueio de heap/vetor
• Aplicar configurações -Xgcpolicy:optavgpause -Xgcpolicy:subpool -Xgcthreads6 no coletor de lixo JVM para reduzir períodos de GC

Voltar para parte superior

Conclusão

Este artigo definiu a carga de trabalho do FileNet usada para ajustar o tamanho do fragmento ORB com o objetivo de impulsionar o uso de CPU. Mostrou como cargas de trabalho determinam configurações ótimas de desempenho em aplicativos FileNet e que nunca há um "tamanho único" quando se trata de ajuste de desempenho. Este artigo também forneceu criação de log e rastreio detalhados no tempo de execução do servidor de aplicativos com pontos de dados vitais necessários para fornecer uma análise útil. Por fim, forneceu os locais exatos onde ajustar o sistema de mensagens ORB e ajustes adicionais no Windows Server 2008 R2, DB2 e WebSphere.

Voltar para parte superior

Agradecimentos

O autor agradece a Christopher J Blythe, Tim Morgan e Dave Royer por prestarem assistência e esclarecimentos nos tópicos discutidos neste artigo.

Recursos

Aprender

• "Troubleshooting: FileNet Content Engine Performance" (nota técnica IBM, dezembro de 2009): Problemas de desempenho no Content Engine podem ser resultado de um grande número de causas. Explore as possíveis questões a serem examinadas quando ocorrem problemas de desempenho.
  
  
• "Understanding how EJB calls operate in WebSphere Application Server V6.1" (developerWorks, julho de 2008): Adquira um entendimento básico de como a comunicação EJB funciona no contexto do WebSphere Application Server.
  
  
• "DB2 Database AUTOCONFIGURE command" (Centro de Informações do IBM DB2 Database para Linux, UNIX e Windows, março de 2010): Entenda o comando AUTOCONFIGURE do banco de dados DB2
  
  
• PerformanceWiki: Ache dicas rápidas de ajuste de plataforma.
  
  
• Seção Gerenciamento de Informações do developerWorks: Saiba mais sobre Gerenciamento de Informações. Encontre documentações técnicas, artigos de instruções, orientação, downloads, informações sobre produtos e muito mais.
  
  
• Mantenha-se atualizado com os webcasts e eventos técnicos do developerWorks.
  
  

Obter produtos e tecnologias

• Elabore seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente no developerWorks.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Fórum do WebSphere Application Server: Discuta questões do WebSphere Application Server.
  
  
• Participe dos blogs do developerWorks e envolva-se com a comunidade My developerWorks; com seu perfil pessoal e página inicial customizada, você pode adaptar o developerWorks aos seus interesses e interagir com outros usuários developerWorks.
  
  

Sobre o autor

Jesse F. Chen é um engenheiro de software sênior no grupo de Gerenciamento de Informação com foco em desempenho e escalabilidade de software. Ele tem 12 anos de experiência de TI em desenvolvimento de software e serviços. Seus projetos recentes incluem integração e otimização de FileNet e DB2, Gerenciamento de Dados Principais e WebSphere Product Center. Jesse também é um contribuinte e palestrante frequente em várias conferências ECM em tópicos de desempenho, escalabilidade e planejamento de capacidade. Ele é bacharel em Engenharia Elétrica e Ciência da Computação pela Universidade da Califórnia em Berkeley e mestre em Gerenciamento em Informações e Sistemas da Universidade de Nova York.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Sobre a carga de trabalho FileNet
• ORB e as APIs FileNet
• Ligue o rastreio ORB no WebSphere
• Analise rastreios ORB
• Ajuste o tamanho do fragmento ORB
• Resultados: Antes e depois
• Outras sugestões de ajustes
• Conclusão
• Agradecimentos
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais