O que este artigo abrange

Desempenho e escalabilidade são de importância fundamental em qualquer ambiente baseado em servidor. Dependendo da complexidade do ambiente, o desempenho pode afetar seriamente a eficiência do software que você está usando. O servidor do IBM® Rational® Requirements Composer Versão 2.0 é formado por diversas partes que trabalham em conjunto para formar o backend da ferramenta. Os componentes do servidor V2.0 podem ser configurados em várias topologias e definições que afetam o desempenho e a escalabilidade.

Uma vez que já tratamos da release inicial, o foco maior deste teste foi o desempenho do servidor e de sua infraestrutura subjacente. Este artigo descreve detalhadamente os componentes do servidor e explica suas diversas configurações e topologias que podem influenciar o desempenho. Também descrevemos as técnicas que usamos para registrar medidas de desempenho e métricas de escalabilidade sob diferentes escalas e topologias e, além disso, investigamos os resultados dos testes.

Abrangemos os detalhes de nossas descobertas por meio de comparações de diferentes topologias, bancos de dados e servidores de aplicativos da Web. Também consideramos os efeitos do escalonamento tanto do número de usuários quanto de recursos no servidor. Além disso, explicamos como é possível recriar nossa configuração de testes em seu próprio ambiente para realizar seus testes de desempenho. Por fim, oferecemos dicas de ajuste de desempenho e especificações para um desempenho ideal do servidor do Rational Requirements Composer.

Isenção de responsabilidade

As informações deste documento são distribuídas NO ESTADO EM QUE SE ENCONTRAM. O uso destas informações ou a implementação de quaisquer destas técnicas é de responsabilidade do cliente e depende da sua capacidade de avaliá-las e integrá-las ao seu sistema operacional. Embora cada item possa ter sido revisado pela IBM quando à precisão em uma situação específica, não há garantia de que resultados idênticos ou semelhantes sejam obtidos em outros contextos. Os clientes que tentarem adaptar estas técnicas aos seus próprios ambientes o fazem por sua conta e risco. Todos os indicadores a Web sites externos, nesta publicação, são fornecidos apenas por mera conveniência e não servem, de forma alguma, como endosso destes Web sites. Quaisquer dados de desempenho contidos neste documento foram determinados em um ambiente controlado e, por isso, os resultados que podem ser obtidos em outros ambientes operacionais podem variar de maneira significativa. Os usuários deste documento devem verificar os dados aplicáveis ao seu ambiente específico.

Voltar para parte superior

Recomendações para um desempenho ideal

Topologia

Ambiente de camada dupla: Um servidor para o servidor de aplicativos e um para o servidor de banco de dados

Banco de dados

IBM® DB2® ou Oracle

Servidor de aplicativos

IBM® WebSphere® Application Server Versão 6.0
Especificações mínimas da máquina

Servidor de aplicativos

• CPU Quad-core de 2,8 GHz e 8 GB de RAM
• Disco: Disco SAS, RAID, SAN de alto desempenho ou subsistema de disco conectado diretamente NAS

Servidor de banco de dados

• CPU com dois núcleos, 2,9 GHz e 4 GB de RAM
• Disco: Disco SAS, RAID, SAN de alto desempenho ou subsistema de disco conectado diretamente NAS

Resumo

O principal gargalo de desempenho é a máquina servidora do aplicativo para diversas execuções de teste com quantidades variáveis de carga. Portanto, é melhor usar um ambiente de camada dupla com a máquina de melhor desempenho hospedando o servidor de aplicativos. Em nossos testes, os bancos de dados IBM DB2 e Oracle manipularam as cargas do usuário de maneira semelhante. Assim, use o software de banco de dados ao qual você e seu cliente estejam mais acostumados. Também descobrimos que o desempenho do servidor de aplicativos é similar para várias cargas do usuário. Preferimos o servidor do WebSphere devido às necessidades empresariais (segurança e administração) dos administradores do Rational Requirements Composer, bem como devido aos seus recursos para ajuste de desempenho customizado.

Observação:
Usamos uma configuração simples do Servidor do IBM WebSphere Application, sem qualquer ajuste adicional.

Voltar para parte superior

Visão geral dos componentes do servidor

O servidor do Rational Requirements Composer cria, manipula e armazena recursos de requisitos usados pelos clientes do Rational Requirements Composer e oferece mecanismos para consultar e pesquisar esses dados. O servidor também oferece serviços específicos para criar, gerenciar e recuperar pastas, tags, comentários, links e capturas instantâneas do projeto.

O servidor é composto por várias partes, cada uma com responsabilidades específicas. No núcleo, o servidor do Rational Requirements Composer é um servidor de aplicativos que executa um conjunto de aplicativos. Existem dois aplicativos principais: um aplicativo do servidor do Requirements Composer e um aplicativo IBM® Jazz® Foundation Server. Existe um aplicativo adicional que usa recursos do Rational Requirements Composer para gerar imagens visualizáveis na Web.

Servidor de aplicativos da Web

O servidor do Rational Requirements Composer consiste em um ou mais servidores da Web ativados para Java™ Enterprise Edition (JEE). O servidor do Rational Requirements Composer suporta o IBM WebSphere Application Server e o Apache Tomcat. A plataforma de tecnologia Jazz e o aplicativo do servidor do Rational Requirements Composer são ambos módulos da Web que são instalados e executados no servidor da Web configurado. Os aplicativos podem ser executados em dois servidores da Web independentes, dependendo da topologia. O desempenho de cada um desses servidores de aplicativos será tratado posteriormente neste artigo.

Jazz e Jazz Foundation Services

O componente do repositório Jazz manipula todo o armazenamento dos artefatos e das informações do Rational Requirements Composer. Jazz Foundation Services é um conjunto de recursos usado para manipular a administração, segurança, colaboração, consulta e outros recursos gerais entre ferramentas para o usuário e o projeto.

O backend do repositório é um banco de dados relacional, que é usado para armazenar todos os recursos e artefatos de servidor. O Jazz Foundation Services pode extrair vários dados estruturados de documentos XML e Resources Description Framework (RDF) e, em seguida, as informações são indexadas, o que permite fácil recuperação e consulta dessas propriedades. Além disso, o Jazz Foundation Services usa um índice de texto separado para pesquisas de texto completo entre recursos (por meio do Apache Lucene).

Para usar ou consultar os dados, solicitações do lado do servidor são convertidas em instruções da Linguagem de Consulta SPARQL e, em seguida, executadas no banco de dados.

Aplicativo do servidor do Rational Requirements Composer

Além dos recursos base do núcleo fornecidos pela plataforma de tecnologia Jazz, funções específicas do requisito devem ser manipuladas no servidor. O Jazz Foundation Services fornece um mecanismo para utilizar um aplicativo frontal, que é um aplicativo da Web do lado do servidor que contém lógica de aplicativo e de apresentação e usa o Jazz Foundation Services para fins de armazenamento, consultas e segurança. O aplicativo do servidor do Rational Requirements Composer é um aplicativo da Web frontal que é executado em um servidor compatível com Java EE, separadamente do aplicativo da Web do Jazz.

Além de fornecer uma função específica do requisito, o mecanismo do aplicativo frontal permite que o servidor do Rational Requirements Composer aprimore o desempenho usando estratégias de armazenamento em cache específicas do domínio dos requisitos. Isso ocorre além do armazenamento em cache padrão fornecido pelo Jazz Foundation Services.

Aplicativo da web do Rational Requirements Composer

O servidor do Rational Requirements Composer inclui a funcionalidade que permite acessar o Rational Requirements Composer a partir de um navegador da Web. Um aplicativo da Web adicional executado no servidor é usado para manipular a conversão dos recursos do Rational Requirements Composer em imagens tamanho miniatura.

Banco de dados

Um banco de dados relacional é usado para persistência dos recursos do servidor. Executamos nosso teste em dois bancos de dados empresariais suportados pelo IBM Rational Requirements Composer 2.0: DB2 e Oracle. Nossos testes concentram-se em cenários empresariais que envolviam um grande número de usuários (não usamos o banco de dados Derby em nosso teste). O Microsoft® SQL Server não foi testado porque não fazia parte do ambiente operacional suportado na época em que realizamos os testes.

Técnicas e ferramentas usadas para medir desempenho e escalabilidade

Observe que os dados discutidos neste artigo são resultado da execução de usuários simulados no servidor do Rational Requirements Composer. As experiências reais do cliente podem ser distintas, dependendo dos ambientes e do uso do cliente.

Rational Performance Tester

O IBM® Rational® Performance Tester é usado para simular e medir as interações cliente/servidor do Rational Requirements Composer. O ambiente do teste é configurado para manipular até 500 usuários virtuais que estejam interagindo com o servidor do Rational Requirements Composer.

Máquina host do Rational Performance Tester

A máquina host executa o ambiente de trabalho do Rational Performance Tester e é responsável por distribuir a carga do usuário e coletar os dados de desempenho. Estas são as especificações da máquina:

• Lenovo ThinkCentre, Microsoft® Windows Server 2003 Enterprise Edition, SP2
• CPU duplo de 2,66 GHz e 4 GB de RAM

A máquina host distribui o carga do usuário de maneira uniforme entre cada um dos agentes de teste do Rational.

Máquinas agente do Rational Performance Tester

O ambiente inclui cinco máquinas agente do Rational Performance Tester. Cada máquina recebe solicitações para um número definido de usuários e envia as solicitações para o servidor do Rational Requirements Composer. A máquina registra os tempos de resposta e os resultados e, em seguida, envia os dados à maquina host. Cada uma das máquinas agente possui as seguintes especificações:

• Lenovo ThinkCentre, Microsoft Windows Server 2003 Enterprise Edition, SP2
• CPU duplo de 2,66 GHz e 4 GB de RAM

Para os dados do teste, a fim de eliminar a máquina agente como gargalo de desempenho, cada máquina agente simula não mais que 100 usuários.

Cenário de teste executado

Existem dois casos de uso que cada usuário irá executar: um caso de uso Autor e um caso de uso Revisor. Cada usuário executa um caso de uso e, em seguida, aguarda por 120 segundos antes de repeti-lo. Não há "tempo pra pensar" adicionado entre operações individuais nos casos de uso. Todas as ações nos recursos são aleatórias. Com base no uso do cliente real, nosso cenário de teste consiste em uma proporção de 1 Autor para 4 Revisores. Um cenário de teste típico executado para 500 usuários produzirá 705 recursos, atualizará 2.287 recursos e criará 5.876 comentários por hora. Isso ocorre juntamente com as outras interações do servidor. A quantidade média de solicitações é de 85.000 por hora. Cada teste é executado por 60 minutos depois que todos os usuários estiverem no sistema.

Caso de uso Autor

Neste caso de uso, o usuário simula o que um típico Autor do Rational Requirements Composer faria. O usuário navega para encontrar um recurso, o visualiza e, em seguida, decide atualizar o recurso ou cria um inteiramente novo. A Tabela 1 mostra as ações executadas pelo usuário.

Caso de uso Revisor

Neste caso de uso, o usuário simula o que um típico Revisor do Rational Requirements Composer faria. O usuário navega para encontrar um recurso, o visualiza e, em seguida, decide adicionar um comentário ao recurso, marcar o recurso com uma tag relevante ou passar para outro caso de uso sem realizar nenhuma ação. A Tabela 2 mostra as ações do usuário.

Planejamento de desempenho do Rational Performance Tester

O planejamento (Figura 3) consiste em diversos casos de uso utilizados para simular os casos de uso Autor e Revisor.

Visualização mais ampla da Figura 3.

Cada etapa de teste interage com o servidor usando Amostras do Rational Requirements Composer, que são um conjunto de amostras Java que demonstram como clientes e parceiros podem interagir com os recursos do Rational Requirements Composer usando as solicitações RESTful. As amostras estão disponíveis em Jazz.net. Após cada interação do servidor, cada usuário reutiliza dois objetos Apache HttpClient para comunicar-se com o servidor por meio de HTTP.

Tempo de rampa e métricas do usuário

Para cada execução de teste, os usuário são introduzidos no sistema em um intervalo normal definido; isso é chamado fase de "rampa". Isso ocorre para assegurar que a introdução de um grande número de usuários no sistema não o sobrecarregará. Os tempos de resposta coletados durante a fase de rampa não será incluído nas métricas. As métricas refletirão os dados coletados quando todos os usuários estiverem no sistema.

Aceitação de falhas

Uma vez que os scripts são aleatórios, a quantidade de carga no servidor varia em diferentes momentos. No caso de uma carga anomalamente grande, o servidor retornará códigos de falha adequadamente. Se a contagem de falhas for inferior a 5% do número total de solicitações, os dados são considerados válidos

Monitoramento dos recursos do sistema

Servidor VMware ESX

No servidor VMware ESX, o monitoramento dos recursos do sistema é feito usando o conjunto de ferramentas de desempenho VMware Infrastructure Client, como mostra a Figura 4. O conjunto de ferramentas permite o monitoramento de CPU, memória e uso do disco.

Visualização mais ampla da Figura 4.

Servidores do Windows

Nos servidores do Windows, o monitoramento de recursos é feito usando a ferramenta de monitoramento de desempenho do Windows (perfmon) mostrada na Figura 5.

Especificações da máquina de teste

Servidor VMware ESX, ambiente Linux

1. Especificações do servidor de aplicativos
   • SuSE Linux® 4.1.2, VM de 64 bits
   • WebSphere Application Server 7.0.0.3
   • Intel Xeon X5365 Quad core com CPU de 3,0 GHz CPU
   • 8 GB de RAM
   • Disco rígido SCSI de 50 GB
2. Especificações do servidor de banco de dados
   • SuSE Linux 4.1.2 com VM de 64 bits
   • DB2 Versão 9.5
   • Intel Xeon X5365 Quad core com CPU de 3,0 GHz
   • 8 GB de RAM.
   • Disco rígido SCSI de 50 GB

* Consulte o apêndice para obter as especificações do servidor ESX

Ambiente Windows

1. Especificações do servidor de aplicativos
   • Windows 2003 Enterprise Server, 32 bits
   • WebSphere Application Server V6.1
   • Intel Core Duo E6750 com CPU de 2,6 GHz
   • 4 GB de RAM
   • Disco rígido SATA de 232 GB
2. Especificações do servidor de banco de dados
   • Windows 2003 Enterprise Server, 32 bits
   • DB2 Versão 9.5.1
   • Oracle 10g
   • Intel® Core Duo E6750, CPU de 2,6 GHz
   • 4 GB de RAM
   • Disco rígido SATA de 232 GB

Configuração do Rational Requirements Composer

Repositórios do usuário

Para eliminar a variável da autenticação remota de usuários, os servidores de aplicativos mencionados neste artigo são repositórios locais de usuários (sem uso do LDAP). O WebSphere Application Server usa o repositório de usuários federado e o servidor do Tomcat usa o diretório de usuários local do Tomcat.

Estrutura do projeto

A estrutura do projeto descrita neste artigo reflete o uso do cliente típico, considerando-se que o usuário comum não terá acesso a todos os recursos no repositório. Os projetos são configurados com projetos de dados, que contêm aproximadamente 80% do total de recursos no repositório. Cada usuário tem acesso a projetos de teste, que respondem por cerca de 20% dos recursos no repositório.

Configurações do IBM WebSphere Application Server

Em máquinas de 64 bits onde estiver disponível memória adicional, o tamanho máximo de heap padrão de 1536 MB da Java™ Virtual Machine (JVM) é aumentado. Isso tem a finalidade de garantir máxima eficiência. Em máquinas de 32 bits, são usadas as configurações padrão.

Configurações do servidor de aplicativos Tomcat

As configurações padrão são usadas para o servidor de aplicativos Tomcat.

Otimização do banco de dados

Para que o banco de dados tenha um desempenho ideal, é necessário otimizá-lo completamente. Com o DB2 e o Oracle, é possível executar estatísticas para permitir que o banco de dados analise a forma de um esquema e otimize seu conteúdo.

Geralmente, os bancos de dados gerenciam estatísticas automaticamente (em uma operação noturna planejada, por exemplo). No entanto, para assegurar que os bancos de dados sejam totalmente otimizados durante nosso teste, é necessário executar manualmente as estatísticas:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL 

EXEC DBMS_STATS.gather_schema_stats(' JAZZDBUSER' ); 

Voltar para parte superior

Resultados do teste de desempenho

Comparação do fornecedor do banco de dados

Neste teste, comparamos o desempenho dos fornecedores do banco de dados. O ambiente é idêntico; a máquina servidora do banco de dados tem o IBM DB2 e o Oracle instalados. Os servidores de banco de dados estão ativos ou inativos, dependendo de qual fornecedor está sendo testado. Os dados são submetidos a backup por meio do IBM® Jazz™ como um backup do sistema de arquivos e restaurados em ambos os bancos de dados.

A comparação do fornecedor do banco de dados é executada no ambiente do Windows com 10.000 recursos, 50 e 200 usuários.

Diferenciar o IBM WebSphere Application Server e o servidor do banco de dados DB2 (Windows)

O ambiente de 32 bits do Windows tem o servidor de aplicativos IBM configurado para comunicar-se com o servidor de banco de dados DB2. O tempo de reposta de solicitação médio para 200 usuários simultâneos é 1.381 ms. Existem flutuações naturais nos tempos de resposta durante toda a execução de 60 minutos.

Diferenciar o IBM WebSphere Application Server e o servidor de banco de dados Oracle (Windows)

O ambiente de 32 bits do Windows tem o IBM WebSphere Application Server configurado para comunicar-se com o servidor de banco de dados Oracle. O tempo de reposta de solicitação médio para 200 usuários simultâneos é 1.321 ms. Existem flutuações naturais nos tempos de resposta durante toda a execução de 60 minutos.

Comparação do banco de dados

Não existem muitas diferenças entre os bancos de dados DB2, Oracle e SQL (suportado na V2.0.0.1) nos tempos de resposta de solicitação (Figura 8). Correlacionados com os dados da Tabela 4, que indica que o servidor de banco de dados é o componente menos usado no sistema, qualquer um dos fornecedores de banco de dados oferecerão o mais alto nível de desempenho. Por isso, use o banco de dados que você ou sua equipe preferir.

Resultados para escalabilidade de usuários e recursos

Diferenciar o WebSphere Application Server e o servidor de banco de dados DB2 (Linux)

Essas execuções de teste mostram o efeito de escalonar o número de usuários simultâneos e o número de recursos no repositório. Os tempos de resposta e os recursos do servidor são monitorados. O ambiente Linux é usado para essas execuções, com as combinações de 200, 350 e 500 usuários e 10.000, 50.000 e 100.000 recursos.

Voltar para parte superior

Análise das métricas de desempenho

Comparação de servidores de aplicativos da Web

Na comparação do servidor de aplicativos Tomcat e do IBM WebSphere Application Server, notamos diferenças insignificantes no desempenho.

Observação:
Usamos a configuração padrão do WebSphere Application Server. Nenhum ajuste adicional de desempenho foi executado no WebSphere Application Server durante a execução dos testes.

A diferença nos tempos de resposta médios para cada agrupamento de usuários nunca é superior a 55 ms. Para lojas de menor escala com menos de 300 usuários, escolha o servidor de aplicativos que esteja disponível e se adapte às suas necessidades específicas.

Número de usuários

Na Figura 10, conforme aumenta o número de usuários, o tempo de resposta médio também aumenta. A comparação da taxa de aumento nos tempos de resposta não mostra uma grande diferença entre os servidores de aplicativos Tomcat e IBM WebSphere. Quando os usuários forem escalonados para 300, use o servidor de aplicativos de sua preferência.

Escalabilidade

Escalabilidade de usuários

Na Figura 9, a introdução de usuários tem um impacto significativo nos tempos de resposta. A maior degradação no desempenho ocorre quando o número de usuários aumenta de 350 para 500. No repositório de 100.000 recursos, os tempos de resposta aumentaram em 130% ao passar de 350 para 500 usuários, em comparação aos 65% observados quando houve aumento de 200 para 350 usuários. A degradação indica que, para este sistema específico, uma carga de 350 usuários simultâneos está próxima à carga ideal para um repositório com 100.000 recursos.

Escalabilidade do número de recursos

Na Figura 9, quando mais recursos são introduzidos, a degradação do tempo de resposta é mínima quando há 200 usuários no sistema. No entanto, quando há 500 usuários no sistema, um aumento de 50.000 para 100.000 recursos leva a um aumento de 37% no tempo de resposta, enquanto para 200 usuários o aumento é de apenas 14%. Concluindo, para nosso ambiente Linux, a introdução de mais recursos tem um impacto significativo no desempenho quando há mais de 200 usuários no sistema. Esse aumento deve-se ao fato de que a indexação e a pesquisa de dados ocorrem no servidor de aplicativos; por isso, o desempenho é afetado conforme aumenta o número de recursos.

Decomposição da escalabilidade

Comparando-se os efeitos da introdução de mais usuários vs. mais recursos, percebe-se que a introdução de mais usuários tem um impacto mais profundo no desempenho (veja a Tabela 3). Porém, se separarmos as interações do servidor entre interações de banco de dados e interações de consulta, será possível ver que um aumento do número de usuários tem um efeito muito maior do que o aumento do número de recursos.

Para interações do repositório, em que o número de linhas no banco de dados irá variar muito entre 10.000 e 100.000 recursos, ocorre um aumento substancial no tempo de resposta. Entretanto, para interações de consulta que envolvem a biblioteca de consulta Jena, a diferença não é aparente.

Resumo

Para obter um servidor escalável com melhor desempenho, use a implementação de camada dupla, com um servidor para o servidor de aplicativos e outro para o servidor de banco de dados. Para implementações de grande escala, use a solução de armazenamento NAS ou SAN para obter melhor desempenho em situações de pesada carga no servidor.

Dimensionamento

Uso de recursos do sistema

Para recursos do sistema, comparamos o uso de recursos da máquina WebSphere Application Server ("WAS" na Tabela 4, a seguir) e da máquina servidora DB2 quando todos os usuários estiverem ativos no sistema.

*WAS = WebSphere Application Server

A elevação no número de recursos tem pouco efeito no uso de memória ou de CPU da máquina do WebSphere Application Server, mas afeta o uso do disco. Para o servidor de banco de dados DB2, aumentar o número de recursos afeta somente o uso de disco. A elevação da quantidade de usuários afeta tanto o uso de CPU quanto o uso de disco na máquina do WebSphere Application Server, mas na máquina servidora do DB2 tem efeito apenas sobre o uso de disco. Ao considerar como dimensionar apropriadamente o ambiente do Rational Requirements Composer, o uso de disco deve ser uma preocupação para o WebSphere Application Server e para as máquinas servidoras do DB2. Especificamente, para a máquina do WebSphere Application Server, certifique-se de que o uso de CPU não é um gargalo de desempenho.

Uso de espaço em disco

O uso de espaço em disco do servidor do Rational Requirements Composer é formado pelo espaço em disco usado para os dados indexados desse mesmo servidor e pelo espaço em disco necessário para a instância de banco de dados. Por padrão, os dados indexados estão localizados na mesma máquina do servidor de aplicativos. Por isso, é importante considerar um espaço em disco adequado.

Por exemplo, para nosso repositório Linux carregado com 100.000 recursos do Rational Requirements Composer, os dados indexados ocupam até 10 GB de espaço em disco. A instância de banco de dados deve estar localizada em um servidor que também tenha espaço em disco apropriado. Por exemplo, o banco de dados que aloja 100.000 recursos do Rational Requirements Composer soma aproximadamente 17 GB de espaço em disco.

Observação:
Em nosso teste, usamos recursos simplificados que não possuíam revisões persistidas anteriores, de forma que o espaço em disco real usado variava com base no conteúdo e no número de revisões de recursos.

Uso da largura da banda de rede

Durante os testes, monitoramos o uso de rede no servidor que estava executando o software IBM WebSphere Application Server e no servidor do DB2.

Observação:
Por padrão, incluindo todos os nossos testes, todo o conteúdo transferido do servidor do Rational Requirements Composer para conexões do cliente usa compactação HTTP, o algoritmo de compactação gzip .

Todas as conexões do cliente usaram HTTPS. A Figura 12 mostra o uso da largura da banda de rede para o WebSphere Application Server e o servidor do DB2 durante os testes, usando números crescentes de recursos e usuários.

Com os resultados, é possível observar que o uso de rede do servidor do WebSphere Application Server foi mais de 40% superior ao do servidor do DB2. Esses dados mostram que é necessário cuidado ao configurar seu ambiente do servidor quando o uso de rede for um fator importante – o WebSphere Application Server utilizará mais largura da banda de rede que o servidor do DB2.

Dimensionamento de hardware

Usando os dados de teste de desempenho que compilamos, criamos a tabela a seguir, com base em várias configurações de hardware e software para uma implementação ideal do servidor do Rational Requirements Composer. Considerando as opções de dimensionamento, a Versão 2.0 suporta configurações de camada única e multicamadas. É possível escolher a configuração de camada única, de menor custo, com a opção de acrescentar uma máquina (configuração de camada dupla) quando sua equipe aumentar.

As três listas a seguir mostram o dimensionamento de diferentes implementações de empresas.
Configuração empresarial de pequena escala, 10.000 recursos e até 100 usuários:

• 2 sistemas: CPU Quad core com 2,4 GHz ou mais, 64 bits
• Memória: 4 GB ou mais
• Sistema operacional: Servidor Linux ou Windows
• Servidor de aplicativos da Web: Tomcat 5.5 ou WebSphere Application Server 6.1 ou posterior
• Banco de dados: Oracle 10GR2 ou DB2 V9.1 ou DB2 V9.5 Fix Pack 4

Configuração empresarial de média escala, 50.000 recursos e até 250 usuários:

• 2 sistemas: CPU Quad core com 2,4 GHz ou mais, 64 bits
• Memória: 8 GB ou mais
• Disco: Disco SAS de alto desempenho (15 K), RAID
• Sistema operacional: Servidor Linux ou Windows
• Servidor de aplicativos da Web: Tomcat 5.5 ou WebSphere Application Server 6.1 ou posterior
• Banco de dados: Oracle 10GR2 ou DB2 V9.1 ou DB2 V9.5 Fix Pack 4

Configuração empresarial de grande escala, 100.000 recursos e até 500 usuários:

• 2 sistemas: CPU Quad core com 2,4 GHz ou mais, 64 bits
• Memória: 8 GB ou mais
• Disco: Disco SAS de alto desempenho (15K), RAID, SAN ou NAS conectado diretamente ao subsistema do disco
• Sistema operacional: Servidor Linux ou Windows
• Servidor de aplicativos da Web: Tomcat 5.5 ou WebSphere Application Server 6.1 ou posterior
• Banco de dados: Oracle 10GR2 ou DB2 V9.1 ou DB2 V9.5 Fix Pack 4

Conectividade de rede

A opção pela conectividade de rede em configurações de camada dupla significa minimizar a latência entre o servidor de aplicativos e o servidor de banco de dados (não mais que 1 a 2 ms), com os servidores localizados na mesma sub-rede. Ao usar armazenamento externo, reduza as latências de conectividade (a configuração ideal ocorre por meio de um Fibre Channel).

Discos

Com base nos resultados do teste de desempenho, descobrimos que um aumento nos recursos, juntamente com um aumento no número de usuários simultâneos, causa elevação na carga no disco rígido. Por isso, em armazenamentos para implementações de grande escala, considere a solução SAN ou NAS com o armazenamento conectado diretamente por meio de uma conexão Fibre Channel (FC), a fim de evitar latência entre o armazenamento e o servidor. O uso desta configuração permitirá a transferência de toda E/S do disco do servidor para o NAS, ao mesmo tempo em que fornece um completo subsistema de disco para tolerância a falhas com recursos de backup de capturas instantâneas, alta disponibilidade e recursos de recuperação de desastre.

Disponibilidade

Configuramos um teste separado de confiabilidade que consistia em observar o servidor por um longo período. A configuração do ambiente para esse teste é semelhante àquela descrita anteriormente. A configuração em si é especificada no Apêndice: Ambiente do Teste de Confiabilidade.

O objetivo do teste de confiabilidade foi determinar o desempenho e a estabilidade do servidor do Rational Requirements Composer por 5 a 7 dias de uso contínuo. Esse teste avaliou as características de desempenho do servidor do Rational Requirements Composer aplicando diversas cargas de trabalho ao servidor durante um longo período de testes e, além disso, medindo o consumo de memória e o uso de CPU realizado pelo servidor.

Após a inicialização, o uso de memória se estabelece de forma aproximada em uma determinada faixa, com aumentos e subsequente reduções de acordo com a carga (veja a Figura 12). O mesmo pode ser visto na utilização do processador (Figura 13). Sob carga, o uso do processador pode sofrer picos, mas não se mantém consistentemente alto.

Durante o andamento do teste, o servidor manteve-se ativo durante 100% do tempo.

Visualização mais ampla da Figura 12.

Visualização mais ampla da Figura 13.

Tolerância a falhas

Como observado anteriormente na seção Aceitação de falhas, os testes executados com um limite permitido de 5% para códigos de erro foram retornados. Esses erros geralmente ocorrem apenas sob carga pesada, em que o número de usuários simultâneos e o tamanho do armazenamento de dados aproximam-se dos limites mais altos dos parâmetros do teste (500 usuários, 100 KB recursos).

A observação do servidor por longos períodos (com variação na carga) mostra que os erros que ocorrem sob carga não têm nenhum impacto futuro nem efeitos adversos em outras solicitações. Esse comportamento pode ser atribuído à arquitetura "sem preservação de estado" do servidor do Rational Requirements Composer.

Erros de tempo limite de OAuth sob carga

A causa comum dos erros que ocorrem sob carga pesada ainda pode ser associada aos tempos de resposta. Nesse caso, não se trata do tempo de resposta entre o servidor e o cliente do Rational Requirements Composer, mas do tempo de resposta entre o servidor do Rational Requirements Composer e o Jazz Foundation Services.

Cada solicitação que o servidor do Rational Requirements Composer realiza no Jazz Foundation Services é autenticada usando o protocolo OAuth (consulte a seção Recursos para saber onde encontrar detalhes). Existe um intervalo entre a concessão de um Token de Acesso ao servidor do Rational Requirements Composer e o atendimento da solicitação pelo Jazz Foundation Services. Se esse período for superior ao Tempo Limite do Token de Acesso OAuth configurado, a solicitação irá falhar porque o Jazz Foundation Services irá rejeitar a solicitação do servidor do Rational Requirements Composer no momento do atendimento. Nesses casos, os logs do servidor devem relatar que os Tokens de Acesso OAuth estão atingindo o tempo limite.

As configurações OAuth podem ser localizadas no cabeçalho OAuthServiceProvider, como mostra a Figura 15.

A elevação do tempo limite do Token de Acesso permite mais solicitações e reduz o número de erros de tempo limite, aumentando assim a confiabilidade geral. É claro que isso envolve o ônus de aumentar os tempos de resposta médios entre o cliente e o servidor do Rational Requirements Composer, porque as solicitações recebem mais tempo para serem concluídas.

Observação:
O valor de tempo limite necessário irá variar dependendo da configuração do servidor.

Ajustes de desempenho

Modificando a frequência das tarefas planejadas do servidor

Há diversas tarefas do servidor executadas de acordo com um planejamento. Quando essas tarefas acontecem, geram carga mais pesada no servidor. Dependendo do uso de recursos do Rational Requirements Composer, a quantidade de carga no servidor pode ser reduzida alterando o planejamento de execução das tarefas. É possível seguir este guia sobre tarefas planejadas e como modificá-las:

1. Feeds de tarefas recentes

Há quatro tarefas atualizadas em um planejamento: artefatos recentes, requisitos recentes, comentários recentes e contagens de tag. Essas tarefas são executadas individualmente para cada projeto do Rational Requirements Composer. Dependendo da frequência de criação ou atualização de artefatos, requisitos e comentários, o impacto que as tarefas causam no desempenho pode ser reduzido. Use estas orientações:

• Se um determinado tipo de operação não for executado muitas vezes, sua frequência pode ser reduzida.
• Se um tipo particular de operação for executado frequentemente, a frequência da tarefa correspondente pode ser aumentada para reduzir a quantidade de trabalho que cada tarefa tem de executar.
• Caso um tipo de tarefa não seja muito importante, sua frequência pode ser diminuída para reduzir a quantidade de trabalho
• O balanceamento da ocorrência das tarefas evitará que todas sejam executadas ao mesmo tempo, levando assim a uma situação em que, por um certo período, as solicitações do servidor são processadas lentamente

Para modificar a frequência das tarefas, o arquivo fronting.properties deve ser modificado. O arquivo está localizado aqui:
<server installation directory>/conf/rdm/fronting.propreties.

Essas são as propriedades correspondentes (todos os valores de propriedades estão expressos em milissegundos, ou ms):

Feed de comentários recentes

Este feed determina quais comentários aparecem no feed de comentários recentes. Ele é acionado pela criação ou atualização de comentários.

com.ibm.rdm.fronting.server.RDMRecentCommentsUpdate.interval=360000

Valor usado durante o teste: 300.000

Feed de artefatos recentes

Este feed determina quais artefatos aparecem no feed de artefatos recentes. Ele é acionado pela criação ou atualização de qualquer recurso do Rational Requirements Composer.

com.ibm.rdm.fronting.server.RDMRecentArtifactsUpdate.interval=420000

Valor usado durante o teste: 420.000

Feed de requisitos recentes

Determina quais artefatos aparecem no feed de requisitos recentes. Ele é acionado pela criação ou atualização dos recursos de requisito do Rational Requirements Composer

com.ibm.rdm.fronting.server.RDMRecentRequirementsUpdate.interval=300000

Valor usado durante o teste: 540.000

Contagens de tag

Determina a contagem do uso de cada tag pública. É acionado pela marcação ou desmarcação de recursos.

com.ibm.rdm.fronting.server.RDMTagCountUpdate.interval=900000

Valor usado durante o teste: 900.000

2. Intervalo persistente de indexação Jazz

Esse intervalo registra o progresso da tarefa de indexação subjacente. Quando o progresso é salvo, as solicitações feitas durante esse tempo demorarão mais que o habitual para fornecer respostas. Assim, aumentando o intervalo de persistência, a quantidade de tempo durante o qual há um comportamento lento será reduzida. A desvantagem é que quando o progresso é persistido, haverá mais dados para persistir. Por isso, se houver uma grande quantidade de criação ou atualizações de recursos, reduza o intervalo de persistência. Se o repositório for usado principalmente para operações somente leitura, aumente o intervalo de persistência para obter melhor desempenho.

A propriedade persistent é modificada usando a página Admin do Jazz e requer privilégios de Administrador.

Propriedades Avançadas: Persistir o progresso do índice a cada N ms

O valor padrão é 60000 ms (1 minuto)

Valor usado durante o teste: 600.000 ms

Voltar para parte superior

Agradecimentos

Agradecemos a Mario Maldari, René Morrow, Jim Yen, Ronald Li, Bhavin Shah e Li Ping Li, da equipe IBM System Verification Test, por fornecer informações sobre testes de confiabilidade.

Voltar para parte superior

Apêndice: Ambiente do teste de confiabilidade

A seção Disponibilidade discute um ambiente separado usado para executar o período de testes contínuo de 5 a 7 dias. Esse ambiente é detalhado na Figura 17.

Teste de confiabilidade: servidor de aplicativos

• XSERIES 3650, Intel® Xeon, CPU 5160 com 3,00 GHz e 8 GB de RAM (usando PAE), Microsoft® Windows® Server 2003 Service Pack 2 (32 bits)
• IBM Rational Requirements Composer Server Versão 2.0.0 (20091105 1210)
• WebSphere Application Server Versão 6.1, Fix Pack 25
• 1024 MB de heap máximo por instância (somente uma instância foi instalada)
• Servidor de banco de dados IBM DB2 (Banco de dados de índice JRSXML, executado no servidor de aplicativos)
• DB2 V9.5, Fix Pack 2a

Teste de confiabilidade: Rational Requirements Composer Client e Rational Performance Tester

• CPU E6750 Intel Core 2Duo com 2,66 GHz, 2,98 GB de RAM (usando Physical Address Extension, ou PAE, Microsoft® Windows® XP (32 bits))
• IBM Rational Requirements Composer Client Versão 2.0 (20091105 1210)
• IBM Rational Performance Tester Versão 8.0.1

Especificações do servidor ESX

• IBM® System x® 3650 (7979MC1)
• Dual Intel Xeon X5365 (3,0 GHz, quad core)
• 16 GB de RAM
• Duas unidades SAS de 15 KB RPM no RAID0

Recursos

Aprender

• Comece aqui para saber mais sobre o Rational Requirements Composer:
  • Assista a esta demonstração de 10 minutos para aprender sobre todo o escopo e recursos.
  • Navegue na página do developerWorks para encontrar outros artigos técnicos e muito mais.
  • Explore a Central de Informações do Rational Requirements Composer.
  
  
• Consulte o wiki JFSCoreSecurity em Jazz.net para ver um tratamento mais detalhado de como aplicativos do Servidor frontal interagem com o Jazz Foundation Services usando o protocolo OAuth.
  
  
• Conheça outros aplicativos na IBM Rational Software Delivery Platform, incluindo ferramentas de colaboração para desenvolvimento em paralelo e equipes geograficamente dispersas, além de software especializado para gerenciamento de arquitetura, gerenciamento de ativos, gerenciamento de alteração e release, gerenciamento de requisitos integrados, gerenciamento de processo e de portfólio e gerenciamento de qualidade. Os manuais, os guias de instalação e a documentação do produto podem ser encontrados no IBM Rational Online Documentation Center.
  
  
• Visite a área do software Rational no developerWorks para obter os recursos técnicos e as melhores práticas dos produtos da Rational Software Delivery Platform.
  
  
• Examine os cursos do Rational (baseados em computador local, baseados na Web e online [conduzidos por instrutor]). Aprimore suas qualificações e aprenda mais sobre as ferramentas do Rational com esses cursos, que abordam desde o nível básico até o avançado. Os cursos neste catálogo estão disponíveis para compra do início ao fim do treinamento baseado em computador local ou do treinamento baseado na Web. Alguns cursos de "Introdução" disponíveis são gratuitos.
  
  
• Assine a newsletter do IBM developerWorks, uma atualização semanal sobre o que há de melhor nos tutoriais, artigos, downloads, atividades da comunidade, webcasts e eventos do developerWorks.
  
  

Obter produtos e tecnologias

• Transfira por download o IBM Rational Requirements Composer e experimente-o, gratuitamente.
  
  
• Faça o download de versões de avaliação de outros softwares IBM Rational.
  
  
• Transfira por download as versões de avaliação do produto IBM e tenha contato com as ferramentas de desenvolvimento de aplicativo e produtos de middleware do DB2, Lotus®, Tivoli® e WebSphere.
  
  

Discutir

• Junte-se à discussão no fórum do Rational Requirements Composer sobre todos os aspectos da definição de requisitos, incluindo conceitos gerais, independentes de ferramentas e informações específicas de ferramentas.
  
  
• Conheça os blogs do developerWorks e faça parte da comunidade do developerWorks.
  
  

Sobre os autores

Nam Le é engenheiro de software da equipe técnica da IBM em Research Triangle Park, Carolina do Norte, EUA. Trabalha na equipe do Rational Requirements Composer Server com ênfase no desempenho do cliente e do servidor.

Tom Mutdosch é engenheiro de software consultivo da IBM no Research Triangle Park, na Carolina do Norte, EUA. Ele trabalha no Rational Requirements Composer Server, concentrando-se em consultar e pesquisar dados de requisitos.

Devang Parikh é gerente de engenharia de software da IBM em Research Triangle Park, Carolina do Norte, EUA. Ele lidera uma equipe do Requirements Server que é responsável por construir a plataforma do servidor usado pelo Rational Requirements Composer.

Bala Kolla é engenheiro de software consultivo da IBM em Research Triangle Park, Carolina do Norte, EUA. Ele trabalha na equipe do Rational Requirements Composer Server.

Chris McGraw é engenheiro de software do IBM Rational em Edimburgo, na Escócia, Reino Unido, e trabalha na equipe do Rational Requirements Composer Server.

Mark Goossen é engenheiro de software da IBM com sede na Pensilvânia, EUA. Ele trabalha na equipe do Rational Requirements Server e concentra-se em processo e configuração.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• O que este artigo abrange
• Recomendações para um desempenho ideal
• Visão geral dos componentes do servidor
• Resultados do teste de desempenho
• Análise das métricas de desempenho
• Agradecimentos
• Apêndice: Ambiente do teste de confiabilidade
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais