Embed Size (px)
Citation preview
© 2009 IBM Corporation
Tunning do WebSphere Portal
Alex Coqueiro
Blog: http://portal-ibm.blogspot.com
1
STORY TITLE
2
Agenda§ Introdução
§ Preparação para os testes
§ Fases do teste
§ Antes do Going-Live
§ Ferramentas de Geração de Carga
§ Estudos de Caso com análise de resultados
§ Parâmetros de Performance
STORY TITLECaracterísticas do WebSphere Portal para Tunning
§ O WebSphere Portal é uma aplicação Web e portanto muitas das técnicas de tunning são as mesmas que utilizamos em uma aplicação Java no WebSphere Application Server
§ A principal diferença está na organização dos elementos da página, pois o Portal criar mini aplicações denominadas portlets.
§ Um portlet com defeito pode comprometer a página inteira.
§ Um dos benefícios do Portal é funcionar como um ponto de entrada para todas as aplicações da empresa. Desta forma o WebSphere Portal está mais sucetível a variações de performance que outros tipos de aplicações.
STORY TITLE
AplicaAplicaççõesões
FerramentasFerramentas
do Timedo Time
ee--RHRH
AplicaAplicaçções ões
de Negde Negóóciocio
ee--Mail & Mail & CalendCalendááriorio ee--LearningLearning
PessoasPessoas
Gerência de ConteGerência de Conteúúdodo Mensagens CorporativasMensagens Corporativas
NotNotíícias cias
PersonalizadasPersonalizadas
Instant Instant
MessagingMessaging
LocalizaLocalizaçção de ão de
EspecialistasEspecialistas
Abordagem Evolutiva de Funcionalidades
STORY TITLEPrincipio de Pareto
O Princípio de Pareto foi criado no Séc. XIX por um economista italiano chamado Alfredo Pareto
que, ao analisar a sociedade concluiu que grande parte da riqueza se encontrava nas mãos
de um número demasiado reduzido de pessoas.
Após concluir que este princípio estava válido em muitas áreas da vida quotidiana, estabeleceu o
designado método de análise de Pareto, também conhecido como dos 20-80% e que significa
que um pequeno número de causas (geralmente 20%) é responsável pela maioria dos
problemas (geralmente 80%).
STORY TITLEPrincipais Problemas
• Não haver planejamento para a realização de testes de performance
• Focar somente em testes funcionais
• Acreditar que o seu código não tem problemas de performance
• Achar que o WebSphere Portal irá resolver todos os problemas de performance da aplicação
• No “desespero” solicitar um documento mágico da IBM para resolver o problema de
performance da aplicação
• Achar que o usuário está sendo exigente e que o tempo de resposta está bom. Não envolver
o usuário final nos testes é um erro muito comum.
• Análise do tipo: Se a aplicação está lenta, favor aumentar a memória ou trocar a máquina.
• Focar testes de performance somente no WebSphere Portal
• Ninguem pensa de massa de dados para o teste
STORY TITLE
7
Agenda
§ Preparação para os testes
– Planejamento
– Determinação dos objetivos de carga e tempo de respostas
– Descrever os casos de teste
– Montar o capacity plan
STORY TITLE
8
Preparação – Planejamento
§ Qual a duração dos testes de performance ?
– Inicie o mais rápido possível no seu projeto
– Alto impacto para correção no final do projeto
– No geral pode variar de semanas até meses
STORY TITLE
9
Preparação – Planejamento§ Quantas pessoas são requeridas ?
– Depende principalmente do tamanho do projeto
– Pode ser de 1 pessoa até uma equipe de testers dedicada
§ Quais os skills requeridos ?
– Depende das ferramentas de testes e da arquitetura do projeto
– Algumas ferramentas dependes de skill mais aprofundado para a realização dos testes
§ Quanto custa ?
– Esta questão depende fundamentalmente da arquitetura, grau de profundidade dos
testes e das ferramentas utilizadas
– Ferramentas comerciais no geral fornecem um detalhamento maior sobre a cobertura dos
resultados, enquanto de ferramentas freeware requerem mais passos manuais
– Hardware e Software adicional pode ser requerido para os testes
STORY TITLE
10
Preparação – Objetivos de Carga e Tempo de Resposta§ Objetivos de carga e tempos de resposta são essenciais para a realização dos testes
– Defina os objetivos do teste
– Defina o custo, pessoas envolvidas e as indisponibilidades do sistema
– Explique o funcionamento do processo de métricas
§ Defina os objetivos de carga no ambiente de produção o mais rápido possível
– Utilize este números para as cargas iniciais e validação das estimativas do “capacity
planning”
– Defina os critéricos de performance a serem atingidos
§ Pense no peak loading antes
– Qual o volume de crescimento do acesso ao seu portal ?
– Há campanhas de marketing planejadas ?
STORY TITLE
11
Preparação – Objetivos de Carga§ Exemplos de Carga baseadas em Transação
– Pages/hour: Taxa de número de páginas por hora
– UC/hour: Taxa de uso do Caso de Uso por hora
– Http requests/hour: HTTP requests por hora incluindo iFrames ou embeded
– Searches/hour: Buscas por hora
§ Exemplos de Carga baseado no usuário
– User visits/hour: Taxa de visita de usuário
– Logins/hour: Taxa de Login
– Active Users/hour: Usuários ativos
§ Obtenção destes números (mesmo que estimados)
– Tente obter do site existente
– Converse com usuários, desenvolvimento, gestores, etc
STORY TITLE
12
Preparação – Objetivos de Tempo de Resposta§ Tempo de Resposta é um objetivo subjetivo
– Percepção do cliente é importante
§ Defina objetivos por atividade de usuário
– Home page, login, funcionalidade, etc.
– Tempo de resposta médio é importante, foque nos percentuais de melhoria
– Transações com diferentes tempos de resposta é o que normalmente acontece
– Estudo objetivos maleáveis em função de condições de acesso diferentes como: Failover,
dial-up, acesso acima do normal
– Compare seus objetivos com dados históricos
STORY TITLE
13
Preparação – Planejamento para PeakLoad§ Sempre desenvolva cenários de teste para horários de pico.
§ Entenda a diferença no tempo de resposta entre o horário de pico e a média dos requestes
– Normalmente o fator varia de 3 a 5 vezes
STORY TITLE
14
Preparação – Definição de Cenário em Caso de Teste§ Use cases descreve como os usuários utilizam o sistema
– Identificar paginas visitadas and atividades chaves como (busca, compra, etc.)
– Exemplo: Home page > Specials page > View item > Add to Cart > ...
– Escrever scripts de testes que simulem este comportamento
– Separe cenários de teste isolados para testar elementos chave da arquitetura
de cenários de teste baseado em requerimento de usuário.
STORY TITLE
15
Preparação – Escrever Casos de Teste§ Escreva cada atividade do usuário com um script
§ Montagem do script
– Script deve usar o sistema na proporção correta. Não exagere ou seja muito
conservador na smulação do usuário.
– Tipicamente, uma boa cobertura de projeto é realizada com 10 a 20 scripts de
teste
§ Use dados representativos
– Forneça um conjunto de dados que permita reuso e evite deadlock ou lock de
conteúdo
– Cuidado com a massa de testes para não enviar emails aos clientes sem querer.
Você tambem é responsável pela massa de dados
– No planejamento leve em consideração o tempo para preparar e revisar a
massa de dados
– Testes reais requerem dados reais
STORY TITLE
16
Preparação – Geração de Dados de Teste§ Testes reais requerem dados reais
§ Logins de usuário
– Cuidado com o reuso de logins de usuário
– Cuidado com as informações em cache
§ Volume no banco de dados
– Sempre que possível tenha uma volumetria de banco parecida com a esperada em
produção
STORY TITLE
17
Preparação – Capacity Plan§ Prepare o capacity plan
– Documento os números obtidos no levantamento de hardware
– Defina tempos de resposta
– Tenha uma porjeção de tempo futuro
– Sempre que possível contate o Techline para montagem do capacity planning
STORY TITLE
18
Preparação – Capacity Plan Backend e Infraestrutura
§ Certifique-se que o Backend tem recursos suficientes para a realização dos testes
§ Cuidado com o dimensionamento de banda de rede ou latência de rede
STORY TITLE
19
Agenda
§ Fases de Teste
1. Teste com um único usuário
2. Teste com um sistema
3. Teste Incremental
4. Teste de Estabilidade
STORY TITLE
20
4 Fases de Teste1. Teste com um usuário único
– Ajuda na análise do código
– Analisa footprint da aplicação
– Ajuda na análise da arquitetura
2. Teste com um sistema
– Inicie com casos de teste mais simples e migre aos poucos para cenários mais complexos
– Identifique e remova gargalos antes de avançar para cenários mais complexos
3. Teste Incremental
– Crescer com a carga
– Identifique e remova gargalos do ambiente como um todo
4. Teste de Estabilidade
– Long runs
– Teste Failover e high-availability
STORY TITLE
21
Fase 1§ Deve ser integrado como parte do processo de desenvolvimento
– Pode ser realizado pelos desenvolvedores
– Integrado aos testes de caixa branca
– Documentar alterações no ambiente de portal como uso de portlet cache
– Oportunidade para rever o código da aplicação
STORY TITLE
22
Fase 1§ Ferramenta
– Análise de código e Degub
– Uso de Rational Application Developer, WebSphere Portlet Factory, Jtest, etc.
§ Criar testes simples de carga
– Um usuário
– Tempo de duração dos teste: 10min a 1h
STORY TITLE
23
Fase 2
Ponto de Teste
STORY TITLE
24
Fase 2
§ Introduz conceito de concorrência
§ Processo Interativo
– Baseline, tune, teste, analise de dados
§ Adicione cenários de teste mais complexos
– Cuidados com a regressão de performance
§ Ferramentas nesta fase
– Ferramentas de monitoração como TPV, ITCAM, vmstat, DB2 snapshots, etc.
STORY TITLE
25
Fase 2§ Baseline
– Verifique números iniciais
§ Teste
– Verifique a duração
§ Observe todos os sistemas e logs
– Utilização de CPU
– Utilização de Disco (I/O) e rede
– O trabalho do Garbage Collection
§ Antes de reexecutar os testes
– Registre os resultados
– Arrume os problemas primeiro
STORY TITLE
26
Fase 2 – Coleta de Dados§ Coleta de Resultados
– Não inclua o tempo de ramp-up/ramp-down
§ Repeat tests
– Reexecute scripts algumas vezes para perceber
comportamento
§ Execução
– Execute o script de 30-45 minutes durante a
fase tuning
– Evite testes em dias de backups de DB, e
manutenção de ambiente
STORY TITLE
27
Fase 2 – Critério de Encerramento§ Sistema apresenta um comportamento estável
– Comportamento estável significa comportamento repetitivo
– Não há erros no log
– Gargalos foram removidos
– CPU do WebSphere Portal está sendo bem utilizada
§ Objetivos de performance atingidos
§ Parâmetros de Tuning (relevantes) foram identificados
§ Planos de ação (Portal, Database, SO, rede) foram definidos
STORY TITLE
28
Fase 3
STORY TITLE
29
Fase 3§ Testar incremental com ambiente integrado
– Verificar se tempo de resposta se mantem estável
– Ajustar configuração de load balance
– Entender impacto de ambientes externos como firewall no projeto
§ Testes considerando cenários de usuários locais e remotos
§ Podemos usar as mesmas ferramentas da fase 2
STORY TITLE
30
Fase 3
§ Processo de Teste similar a fase 2
§ Dimensione ferramentas para simulação de
usuários para evitar gargalos na ponta
§ Esta fase normalmente apresenta
recomendações de Tunning para o usuário
STORY TITLE
31
Fase 4 – Testes de Estabilidade§ Scripts executando durante um longo tempo
– Cubra diferentes horas do dia (preferenciamente 24h)
– Deixe o script rodando em finais de semana
§ Teste de Failover
– Simule falhas de hardware e software para estudar comportamento do sistema e ver se
action plan está sendo seguido
– Validar tempo de resposta em situações de failover
STORY TITLE
32
Fase 4 – Testes em condições normais
STORY TITLE
33
Fase 4 – Testes em condições de falha
STORY TITLE
34
Fase 4 – Critérios de encerramento§ Resultados desta atividade
– Logs estão limpos
– Tempo de resposta estável
– Utilização de recursos contantes
– Fragmentação de JVM baixa
§ Failover
– Requestes não foram perdidos e sessões do usuário foram mantidas
– Portal tem condições de manter disponibilidade mesmo em caso de falhas
STORY TITLE
35
Agenda
§ Antes do Going-Live
STORY TITLE
36
Antes do Going-Live§ Aplique os parâmetros de tuning em produção
– Parâmetros de J2EE
– Parâmetros para os portlets
– Configurações de Sistema Operacional, WebServer
– Configuração no backend
– Garanta a compatibilidade entre as versões do ambiente de homologação e produção
STORY TITLE
37
Antes do Going Live – Rollout§ Considere impacto em diferentes estratégias
– Rollout x Big bang
§ Rollout
– Portlets / grupos de usuários são adicionados em ondas
– Reduz o risco de problemas iniciais de performance
– Considere as dificuldades de alterar o ambiente após o inicio das operações no
site
§ Big bang
– Todos os usuários são movidos ao mesmo tempo para o Websphere Portal
– Importante o sistema funcionar muito bem nos primeiros dias
– Mantenha uma estratégia de switch back para a versão antiga do portal em
caso de contingência
STORY TITLE
38
Ferramentas de Geração de CargaØ Comerciais
§ IBM Rational Performance Tester
§ Mercury LoadRunner
Ø Ferramentas Open Source
§ OpenSTA
§ JMeter
Ø Outras Ferramentas
§ Grinder
§ TestMaker
STORY TITLE
39
IBM Rational Performance Tester
Ø Baseado no Eclipse
Ø Rica API para a formação de
cenários e scripts de execução bem
flexíveis
Ø Relatório bem completo
STORY TITLE
40
Mercury LoadRunner
Ø Pode ser encontrada em alguns clientes
Ø Compatível para testes com o WebSphere
Portal
STORY TITLE
41
JMeter
Ø Pode ser utilizada para testar banco de
dados, ftp, legados, etc
Ø Cobertura de informações bem abrangente
Ø http://jakarta.apache.org/jmeter
Ø Ferramenta baseada em Java
STORY TITLE
42
Open Systems Testing Architecture (OpenSTA)
Ø Boa capacidade gráfica de apresentação de
dados mas apresenta limitações na
configuração de cenários
Ø Pode exportar dados diretamente para
planilhas eletrônicas
Ø http://www.opensta.org
Ø Ferramenta baseada em Windows
STORY TITLE
43
Testes de laboratório
Usuário Virtual (vuser)
Testes reais de usuário
Usuário Real
14 pages views em 6 segundos
logou 51 vezes em 5 minutos
Resultado de:
14 pages views em 5 minutos
logou 1 vez em 5 minutos
Resultado de:
2.3 pages por segundo 0.05 pages por segundo
Se o Portal foi dimensionado para 400 páginas por segundo
170 usuários suportados 8000 usuários reais suportados
Carga gerada pelas ferramentas de teste Carga gerado por humanos
vuser
USERIDn
PWn
Lo
ad
Ge
nera
tor vuser
vuser
vuser
vuser
vuser
USERIDx
PWx
...
...
Pense nos números como humanos
STORY TITLEExemplo de Captação de Dados
A interpretação dos números é um elemento muito importante na análise dos dados. Abaixo
vamos analisar os resultados.
STORY TITLE
Comparativo entre indices de performance(tempo em milisegundos x atividade de tunning)
0
2000
4000
6000
8000
10000
12000
Base
Ora
cle
WebS
erve
r
Net
workin
g Sola
risW
PS D
ataso
urce
WPS
Web C
ontain
erW
AS JV
M/G
C
WP
S Portl
et Cach
e
Login
Portlet App
STORY TITLEParâmetros de Tunning
• Inicie Tunning pelos adequando os parâmetros de WebSphere Application Server
– Parâmetros de ambiente (ulimit)
– Parâmetros de rede (tcp/ip)
– JVM e WebContainer
• Estude o WebSphere Portal Tunning Guide
– Adeque os parâmetros de banco de dados
– Adeque os parâmetros específicos de WebSphere Portal.
STORY TITLEParâmetros de Portal
JVM de 32 bits x 64 bits
Em computadores de 64 bits podemos ter um endereçamento de memória superior a 2.5GB
(limite máximo de 32bits de 4GB)
Entretanto cuidado por objetos que contém referências múltiplas de memória apresentam
tamanho significativamento maior em ambientes de 64bits.
Analise o seu portal e caso ele tenha um baixo uso de memória, endereçamento de 32 bits
possuem uma melhor performance.
Hyper-Threading
Os testes de laboratório da IBM constataram que o uso de Hyper Threading (HT) em
servidores Intel ou Simultaneous Multithreading (SMT) em power series influemciam
positivamente na performance do WebSphere Portal.
Instalação do Portal
O portal possui um parâmetro de instalação denominado “development mode”. Este
parâmetro é indicado para ambientes de desenvolvimento, mas não apresenta otimizações
de performance. Portanto ele nunca deve ser usado em produção.
STORY TITLEParâmetros de Portal
Heap management: O parâmetro de heap size é diretamente proporcional ao montante de
memória utilizada pela sua aplicação. Necessário um balanceamento entre o heapsize e a
memória fisica da aplicação
Exemplo: 2GB de RAM em um máquina Windows 32bits um valor máximo para heap size é
1408MB. A mesma configuração em AIX seria mais adequado com o 1792MB e em Linux
com kernel superior a 2.6 o valor seria 2048MB.
Igualar o heapsize minimum e maximium evita a fragmentação da memória. A implicação
disto é muitos portlets usando pouca memória podem apresentar degradação do
sistema. Um número adequado para o exemplo acima nesta situação seria 320GB.
Web Containers
Um bom parâmetro inicial é maxthreads=50 (WebSphere Administrative Console: Servers ->
Application Servers -> WebSphere Portal-> Additional Properties: Thread Pools-> Web
Container -> Thread Pool - Minimum size threads - Maximum size threads)
STORY TITLEParâmetros de Portal
Portlet Caching e Cache Manager Service
Caches portlets são realizados no web container
“Aggregator”engine constrói as páginas a partir dos portlets
As informações mais antigas do cache são descartadas quando não mais mais espaço para
geração do cache.
Portlet caching trabalha melhor com portlets mais maiores e mais complexos
STORY TITLEParâmetros em banco de Dados
Use Tivoli Performance Viewer para refinar os parâmetros
Prepared Statement Cache é um parâmetro que normalmente precisa ser adequado
Connection Pool é outro parâmetro importante a ser observado pelo TPV
Reorganize os databases do Portal após a realização de uma grande carga de testes
(db2 reorgchk update statistics on table all)
Não utilize Cloudpsace ou Derby em ambiente de produção. Utilize sistemas de banco de dados
que privilegiem a performance como por exemplo DB2.
STORY TITLELDAP
Verifique se o LDAP tem capacidade suficiente para suportar a nova carga gerada pelo
WebSphere Portal
Filtros de LDAP tem um impacto bastante grande na performance do Portal
Na configuração do Portal, há alguns filtros pré-configurados. Analise junto com o
especialista de LDAP para ver se estes filtros estão de acordo com o que foi configurado
no ambiente
STORY TITLEWeb Server (Parâmetros a
serem analisados)
STORY TITLEPortlet Development
No desenvolvimento com Portal, seus componentes (portlets) são pedaços da sua página.
Mantenha a menor quantidade possível de dados na sessão.
Seus portlets não são os únicos na página
Cuidado com os logs. Caso esteja usando o logging API, verifique se o mesmo está habilitado.
“if(getPortletLog().isDebugEnabled())” antes de escrever no log.
Cuidado com a instrução try, catch, finnaly no Java no fechamento das conexões. Muito comum
os desenvolvedores esquecerem de fechar as conexões em situações de exceção.
STORY TITLEWeb 2.0
O Websphere Portal possui um tema que utiliza os potenciais de implementações AJAX.
Cuidado especial nos testes com este tema.
Para alterar os parâmetros de cache que são utilizados por este tema é necessário alterar o
arquivo NavigatorService.properties. Os parâmetro que geram impacto são
remote.cache.expiration.feed.cm, remote.cache.expiration.feed.nm,
remote.cache.expiration.feed.lm e remote.cache.expiration.feed.pm.
STORY TITLEWeb Content management
No geral os mesmos parâmetros utilizados pelo WebSphere Portal são aplicáveis ao WCM.
As maiores diferenças estão no uso de cache, thread de Web Container e conexões de data
source do JCR.
Normalmente os servidores de Authoring e Publishing tem valores de tunning diferentes.
Importante lembrar que o uso de Authoring e Publishing na mesma máquina tem impacto direto
na performance do Portal
STORY TITLE
56
Resumo § Garanta um planejamento do seu teste o mais rápido possível
– As melhorias de performance não dependem única e exclusivamente do
servidor de deployment
– Duas semanas antes de encerrar o projeto não é o ideal para iniciar os testes de
performance e tunning
– Entenda que quanto mais refinado o teste, maior o tempo e recursos necessários.
Estabeleça um plano de testes realista.
§ A preocupação com performance deve extrapolar as fronteiras do administrador do Portal
– Performance é um trabalho que aplica-se a todas as camadas Web, Network, Portal, DB e
sistemas legados.
§ Envolva o cliente no processo de testes para eles entenderem os gargalos
STORY TITLE
57
Maiores Informações WebSphere Portal Information Center:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp
The Tuning section of the WebSphere Application Server Information Center located at:
http://www.ibm.com/software/webservers/appserv/was/library/
WebSphere Portal Benchmark Results:
Contact WPLC Performance team.
DB2 Information Center:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
The ROLTP factors for IBM pSeries Servers™ can be found at
http://www.ibm.com/servers/eserver/pseries/hardware/system_perf.html
WebSphere Application Server Performance information:
http://www.ibm.com/software/webservers/appserv/was/performance.html
Recommended reading list: J2EE and WebSphere Application Server
http://www.ibm.com/developerworks/websphere/library/techarticles/0305_issw/recommendedreading.html
WebSphere Application Server Development Best Practices for Performance and Scalability:
http://www.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Diagnosing Performance Problems for WebSphere Portal 5.1 (though this document was written for WebSphere Portal 5.1, the lessons apply to WebSphere Portal 6.1 as well):
http://www.ibm.com/support/docview.wss?uid=swg27007059
STORY TITLE
58
Questions
