Nesta sessão abordamos a performance de Sistemas de Informação desenvolvidos na plataforma ASP.NET com recurso a SQL Server com SGBD. Iremos explicar como surgem os problemas de performance em sistemas com alguns anos de existência e qual a abordagem a tomar, quando temos utilizadores insatisfeitos.
Abordaremos também alguns casos de sucesso no mercado a nível de sistemas de alta disponibilidade e como o mercado tem evoluído. De uma forma geral, pretendemos demonstrar técnicas de análise/tuning de performance em ASP.NET e sua evolução ao longo das várias versões, como também algumas técnicas de requisitos para obtenção e estruturação da informação.
Finalmente, o objetivo passa por divulgar procedimentos, técnicas e ferramentas que sirvam como uma referência que possam ser úteis caso surjam problemas de performance nos nossos sistemas de futuro, entre os quais : Do’s & Dont’s, Systematic Tuning, ASP.NET Trace, VS Profiling Tools, SQL Profiler entre outros.
2. • Desde 2007 a trabalhar em Sistemas de Informação Web.
• Atualmente a trabalhar na área de Peritagens na maior seguradora do país.
• Tive a oportunidade de trabalhar nas áreas de Negócio - Banca, Saúde, Justiça,
Telecom e Seguros.
• Sempre em ASP.NET!!
Luís Paulino
Cool Things:
Consultor Informático (Outsourcing) desde 2010.
Lic. Engenharia Informática
luiscunhapaulino@gmail.com
pt.linkedin.com/in/luismpaulino
6. ASP.Net Performance – A pragmatic approach
Agenda
I. Sistemas “Reais” e a génese dos problemas de Performance .
II. Conceitos Gerais Tuning
III. Importância da sistematização dos processos de Análise, de Tuning
e de Validação
IV. Técnicas clássicas e Ferramentas ASP.NET – Do’s & Dont’s
V. Algumas novidades de performance na Framework .NET 4.5
7. Manutenção de Sistemas
A. Manutenção Corretiva
– Correção de erros de design ou pressupostos errados.
B. Manutenção Adaptativa/Evolutiva
– Criação ou alterações de funcionalidades dos sistemas de forma
a albergar novas regras e/ou mais informação.
C. Manutenção Preditiva
– Criação ou alterações de comportamentos que têm como
objetivo melhorar a performance do sistema de informação.
- Devido a vários fatores corporativos existe a tendência para
descurar a Manutenção Preditiva em projetos de manutenção.
8. Tuning’s há muitos…
Sistemas “Maravilha”:
• Design moderno
• Novas tecnologias incluídas
• Built from scratch
• State of the Art
Sistemas “Reais”:
• Design confuso
• Tecnologias desatualizadas
• Construído ao longo do tempo
• Manter é a Arte
9. • Tipicamente:
– SI’s de organizações médias e grandes.
– go live à mais de 4 anos.
– Elevada rotatividade de recursos.
– Nº elevado de funcionalidades e regras.
– Tecnologias outdated.
• Problemas comuns
– Falta de documentação.
– Falta de Gestão de Alterações.
– Desnormalização da BD ao longo do tempo.
+ sobre sistemas “Reais”
+ Cedo ou + tarde irão surgir
problemas de performance
10. i. Registar o problema como um
Incidente na KBDB.
ii. Validar a situação. Comunicar se
necessário com Service Desk.
iii. Comunicar incidente ao Service
Manager.
iv. Comunicar através do modelo RACI
v. Estabelecer pressupostos:
Ex: Sistema Disponível e Acessível,
Arquitetura eficaz e fechada, SGBD,
plataforma Web, etc. (Know your Enemies).
Documente-se e pesquise boas práticas,
está tudo na Web!
Pré-Análise
vi - Criar/Rever SLA’s – Service Level
Agreement’s – com o cliente.
Ex: O sistema deve: carregar a página X em
não + de 3 segs com 100 utilizadores
online/s, Carregar grelha de resultados X
em não + de 5 em pesquisa default, etc.
(Know your Allies).
11. If you know what you are looking for,
you are more apt to find it.
in “The Art of Insight, How to have more AHA! Moments “
13. Ciclo de Performance Tuning
Recolher Dados &
Medir
Analisar &
Identificar
Configurar &
Desenvolver
Testar Resultados
Baseline
1. Estabeleça uma baseline.
- Assegure-se que tem um conjunto de objetivos de performance bem
definidos, planos de teste e métricas base.
2. Obtenha Dados & Meça
- Simule carga e capture métricas de performance.
3. Analise & Identifique Problemas e Melhorias.
- Documente-se.
- Identifique problemas de performance e bottlenecks
4. Configure & Desenvolva
- Otimize a sua aplicação alterandos os pontos identificados na análise.
5. Teste Resultados
- Teste continuidade de comportamentos e meça para verificar que as
alterações foram benéficas.
Quando as otimizações
satisfizerem os objetivos.
Este ciclo é uma instância do ciclo sistemático
Medir-Avaliar-Melhorar-Aprender de Quality Assurance.
14. Baseline
Conheça os seus objetivos
Inputs:
• Desenho da aplicação, arquitetura e da
infraestrutura.
• Recolher/Definir os requistos QoS
(SLA’s)
• Contragimentos de utilização da
infraestrutura.
• Requisitos de capacidade de carga
inerente da análise de marketing (DW e
BI)
• Cenários e documentação de desenho
para os casos de uso mais significativos.
Outputs:
• Um documento de modelação
da performance que inclua a
informação levantada no
processo de obtenção
• Caso de teste com objectivos
definidos.
Processo de obtenção Baseline
1. Identificar:
1. Cenários Chave;
2. Workload;
3. Objetivos de performance;
4. Orçamento;
5. Passos do processamento;
2. Alocar Orçamento;
3. Avaliar & Validar.
Garantir sempre o retorno rápido à
Baseline criando Configuration
Item do sistema para poder voltar!
15. Quais os indicadores + relevantes?
Recolher Dados
& Medir
Legenda:
R: tempo de resposta
RTT: round trip time
App Turns: Http Requests
Concurrent Requests: # sockets abertos pelo
browser no servidor
Cs: latência ou tempo de computação no servidor
Cc: latência ou tempo de computação no cliente
Equação da Performance de um pedido:
Throughput
ASP.NET ApplicationsRequests/Sec Web ServiceISAPI Extension
Requests/sec
ASP.NETRequests Current
ASP.NET ApplicationsRequests Executing
ASP.NET ApplicationsRequests Timed Out
Worker Process
ASP.NETWorker Process Restarts
Tempo de resposta/ latência
ASP.NET Request Execution Time
ASP.NET ApplicationsCache Total Entries ASP.NET ApplicationsCache Total
Hit Ratio
ASP.NET ApplicationsCache Total Turnover Rate
ASP.NET ApplicationsCache API Hit Ratio
ASP.NET ApplicationsCache API Turnover Rate
ASP.NET ApplicationsOutput Cache Entries
ASP.NET ApplicationsOutput Cache Hit Ratio
ASP.NET ApplicationsOutput Cache Turnover Rate
Cache
Existe uma miríade de ferramentas de profiling built-in no VS descubra-as!
16. • Criar uma lista de verificações a fazer baseada nos dados recolhidos
anteriormente e siga-a.
• Utilizar Debug & Trace q.b.
• Identificar problemas de desenho e comunique com os stakeholders.
• Identificar bottleneck’s.
• Produzir um documento que identifique a lista de melhorias propostas
• Identificar a camada e módulo a melhorar
• Os recursos envolvidos
• Os itens do módulo a serem revistos
• Os riscos inerentes das alterações
• Os ganhos de performance previstos.
• O plano de transição (novo Configuration Item) de forma a albergar
as alterações no deploy.
• Utilize ferramentas de análise disponíveis no mercado.
Por onde começar?
Plan Your Dive *
17. Ao identificar bottlenecks verificar se:
• fluxos + relevantes afetam a performance.
• uso de recursos ou computação afeta a performance.
• fluxos + frequententes.
• passos em que os recursos são acedidos provocando constrangimentos
• computação vs localização dos recursos.
• Quais os compromissos que foram feitos de forma a maximizar a performance?
• Quais os componentes que estão relacionados com outros componentes e/ou
recursos?
• Quais são as chamadas feitas síncrona e assíncronamente?
• Quanto é o trabalho de I/O e o trabalho de processamento?
Identificar Bottlenecks
Análise &
Identificação
18. Configurar & Desenvolver Dive Your Plan *
• Limite as alterações às previstas na fase de análise.
(Não tente optimizar tudo de uma só vez, numa só iteração)
• Mantenha as alterações num repositório de source control.
• Implemente as alterações incrementalmente sempre que possível.
• Reveja as melhores práticas utilizadas atualmente no mercado.
• Procure a ajuda de especialistas nas comunidades.
• Crie um documento que reflita as alterações necessárias à futura
transição para modo release.
• Documente e forme a equipa em relação às melhores práticas
implementadas.
20. .NET Performance (CLR)
• CLR - Common Language Runtime é a máquina virtual .NET
• “Common” porque permite várias linguagens traduzindo-as em IL
• O CLR não é um interpretador!
- Ele não retraduz o código em Intermediate Language (IL) cada vez que executa um mesmo código.
- O que o CLR faz é compilar código IL em código máquina antes de executá-lo – Just In Time compiling
• Este processo leva algum tempo mas normalmente só precisa de ser feito 1ªvez.
• Uma vez compilado o código mantém-se disponível para execução. *
• Código não usado nunca é compilado JIT.
• Podemos usar NGEN em vez de JIT se necessário boost na performance.
• Permite optimizar as aplicações em compile time e runtime.
source code
C# Code
VB.NET
Code
.NET
Supported
Languages
source code compilation
C# Compiler
VB.NET
Compiler
Other
Supported
Compilers
runtime compilation
Native Code
Common Intermediate Language (IL)
21. Optimizações CLR (/optimize+ flag )
• É feita uma
optimização dos
fluxos do código
(Branches
optimization)
• A optimização do
compilador JIT fica
também ligada.
// Use /optimize+ compiling option!!
void CLROptimizeExample() {
int unusedVar; // unusedVars are removed
int defaultCompileValue = 0;
while (defaultCompileValue < 20) {
try {
// unreachable code is removed
if (defaultCompileValue == 21) {
unusedVar++;
break;
}
}finally { /* empty finally blocks are removed*/ }
try {/* empty finally blocks are removed*/
} finally { defaultCompileValue++; }
try {/* witht an empty try all blocks are removed */
} catch (Exception) {throw;}
}
}
22. Do’s em .NET Do’s
Release/Análise = <compilation
debug=“false"/>
void DotNetBadExample() {
const string _myString = "1234567890 netponto";
int i = 0;
for (; i < 20; i++) {
if (_myString.Length > 20 & myContains(_myString, ref i)) {
i = i + 1;
}}}
void DotNetGoodExample() {
const string _myString = "1234567890 netponto";
for (int i = 0; i < 20; i++) {
if (_myString.Length > 20 && myContains(_myString, ref i)) {
i += i + 1;
}}}
• Usar switch.
• Usar Generics. ex: List<T>() em vez de ArrayList()
• Manipulação de strings diferente porque são objetos imutáveis.
• Sol.: Usar StringBuilder em vez de operador de concatenação: + em C#,
& VB.
23. Minimizar e Aggregar Do’s
.CSS
• Minimizado (sem espaço em branco e sem comentários)
• Num ficheiro (bundling)
• Remover overwrites;
• Usar reduções nas propriedades
• Incluir ícones como background image em vez de Image
• Css sprites
• Jquery em vez de Javascript tradicional
• Jquery.min.{version}.js em modo Release
• Link Directo em vez de ficheiro local
• Utilizar Client-Side Validation
• Minimizado
• Usar Identificadores HTML 5
• Usar CSS classes em vez de style,
• Especificar dimensões imagens.
• Usar CSS para efeitos e Javascript para
comportamentos.
• Incluir scripts depois do markup ou assíncronos
24. Reduzir interacões
• Reduzir dados, markup, imagens transferidos por req.
• Utilizar paginação na obtenção de grandes conjuntos
de dados.
• Desligue o ViewState e Session em páginas que não
estiver a utilizar
• Minimize o nº de objectos presentes no ViewState.
• Considerar utilizar HTTP Compression.
• Usar Id’s pequenos
• Use JSON em vez de XML
Do’s
Reduzir
Round Trips
• Considerar usar HTTPResponse.IsClientConnected para
verificar se o cliente continua ligado antes de
operações pesadas no servidor. (medir para ver se
melhora).
• Utilize Server.Transfer em vez de Response.Redirect se
possível.
Reduzir
Page.Size()
25. Executar só se necessário Do’s
• Usar e “abusar” : !Page.IsPostBack, !Page.IsCallback,
!Page.IsCrossPagePostBack
• Dividir a página por conteúdos de forma a aumentar a
eficiência da cache e da renderização, usar UpdatePanels e
Ajax
• Utilize Cache’s, cuidado com os limites e use SQLInjection.
• Usar a Output Cache em páginas relativamente estáticas.
– Pode sempre antecipar expiração através de:
HttpResponse.RemoveOutputCacheItem(“/MyPage.as
px”);
• Remover Módulos HTTP do Pipeline ASP:NET se não os
estiver a utilizar.
• (….)
27. Tratar bem os Recursos Do’s
• Usar StopWatch em vez de Final Datetime –Initial Datetime
• Afinar a Thread Pool.
• Close e/ou Dispose sempre os recursos que abriu explicitamente
– e não os bloqueie ou meta em cache
using(<open connection>){
} // dispose automático
Configuration setting Default Recommended
maxconnection 2 12 * #CPUs
maxIoThreads 20 100
maxWorkerThreads 20 100
minFreeThreads 8 88 * #CPUs
minLocalRequestFreeThreads 4 76 * #CPUs
28. Do’s em BD’s
• Escolher o .NET Data Provider correto
– Evite OLEDB, System.Data.SqlClient (SQL Server), ODP.NET (Oracle), etc.
• Usar Connection Pooling.
• Usar Stored Procedures em vez queries.
• Usar MARS (Multiple Active Result Sets).
– Retorne múltiplas tabelas para dentro dum DataSet
• Normalizar e redesenhar modelo dados se necessário.
• Evitar Joins (Use select’s diretos em queries complexas).
• Fechar sempre as ligações BD e outros recursos Pooled.
• Deixar a BD em paz, Lazy Loading rocks!
• Não pressuponha nada, investigue comportamento CLR, IIS, SGBD, etc.!
Do’s
29. Dont’s
• Over Initialize.
• Não chamar o garbage collector GC.Collect() e não chamar Finalizers a la C++;
• Evitar o uso de exceções desnecessárias:
– Para controlo de fluxo.
– Especialmente exceções não geridas! Quanto + perto melhor!
– Nunca apanhar uma exceção só para a lançar de seguida.
– Não tenha medo de usar blocos Try Catch Finally eles não afetam a performance.
• Evitar chamar Page.Bind
• Minimize chamadas DataBinder.Eval, em vez disso usar Cast explícito para DataItem.
• SessionState:
- Evite guardar objetos STA COM
- Evite guardar Session State se não o usar.
Dont’s
30. Testar
Resultados
Validar melhorias
e comportamentos
• Medir a comparar os valores dos indicadores iniciais, investigar outros indicadores relevantes.
• Verificar se as medições estão corretas, se foram produzidas nas mesmas condições e se cumprem SLA’s.
• Verificar sempre que o comportamento esperado do sistema se mantém.
Teste de Carga em 5 passos
Inputs: Objetivos Performance, workload, Aplicação, planos teste
1. Identificar cenários chave.
2. Identificar workload
3. Identificar métricas
4. Criar casos de teste
5. Simular carga
6. Analisar resultados
Outputs: Plano de testes atualizado, capacidade máxima,
comportamento com várias cargas,
potenciais bottlenecks, recomendações para bottlenecks
Testes de Stress
Estender os testes de carga
Para além dos limites impostos
pelos SLA’s
É uma boa ideia, especialmente em
sistemas críticos.
Deve-se preparar alguns testes de
stress nos pontos mais críticos, i.e.
que exigem uma maior
disponibilidade e/ou carga.
31. • Melhoramentos no carregamento de páginas:
• bundling e minimização de scripts e CSS.
• Capacidade de obter informação de diagnóstico de performance nos
servidores e na cloud.
• Melhoramentos ao nível do binding em web forms.
• Capacidade de ler e escrever pedidos HTTP de forma assíncrona.
• Suporte para módulos e handlers assíncronos.
Novidades ASP.NET 4.5
32. Wrap Up
• Abordar o problema como incidente em encaminhá-lo ao longo dos processos numa
metodologia de performance tuning.
Know your goals in every step & Keep Track
• Documente-se previamente e estabeleça objetivos e metas.
Know your enemies, Know your allies & Act wisely
• Desenvolver plano de melhorias e executá-lo rigorosamente, sem desvios de âmbito.
Plan your Dive, Dive your Plan
• A manutenção preditiva é um processo contínuo e deve ser feita desde início.
• Valorize o trabalho efetuado, comunicando quantitativamente os ganhos.
Improve your visibility as a performance tuning expert!
33. Ainda interessado?
MSDN – Performance
http://msdn.microsoft.com/en-us/library/ms998549
http://msdn.microsoft.com/en-us/library/aa292152(v=vs.71).aspx
http://msdn.microsoft.com/en-us/library/cc668225(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/3xxk09t8(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/ms178139%28v=vs.100%29.aspx
10 ASP.NET Performance and Scalability Secrets
http://www.codeproject.com/Articles/23306/10-ASP-NET-Performance-
and-Scalability-Secrets
SQL Server Performance Monitoring and Tuning How-to Topics
http://msdn.microsoft.com/en-us/library/ms187830(v=sql.105).aspx
Oracle Database Performance Tuning Guide
http://docs.oracle.com/cd/B13789_01/server.101/b10752/perf_overview.htm
NP .Net Profiler
troubleshooting-performance-issues-in-web-application