ASP.Net Performance – A pragmatic approach - Luis Paulino

1.251 visualizações

Publicada em

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.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.251
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
11
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

ASP.Net Performance – A pragmatic approach - Luis Paulino

  1. 1. 40ª Reunião Presencial @ LISBOA DateTime.Parse(“27-07-2013", new CultureInfo("pt-PT")); http://netponto.org hashtag #netponto
  2. 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
  3. 3. Patrocinador “GOLD” Twitter: @PTMicrosoft http://www.microsoft.com/portugal
  4. 4. Patrocinadores “Silver”
  5. 5. Patrocinadores “Bronze”
  6. 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. 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. 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. 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. 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. 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 “
  12. 12. Conceitos de Performance Tuning SLA Throughput Profiling & Instrumentation Escalabilidade Performance Analysis LatencyPerformance Tuning Bottleneck
  13. 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. 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. 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. 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. 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. 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.
  19. 19. Performance .NET Do’s Dont’s
  20. 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. 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. 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. 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. 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. 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. • (….)
  26. 26. Let’s see some tricks! ASP.NET Performance Demo
  27. 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. 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. 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. 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. 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. 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. 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
  34. 34. Patrocinador “GOLD” Twitter: @PTMicrosoft http://www.microsoft.com/portugal
  35. 35. Patrocinadores “Silver”
  36. 36. Patrocinadores “Bronze”
  37. 37. Próximas reuniões presenciais • XXXVII Encontro Da Comunidade SQLPORT (PORTO) 20 Jul 2013 - 10:00 "Extended events practical cases" - Vitor Pombeiro • 24Hours da PASS - 31 Julho 12:00 Practical Performance Troubleshooting - Brent Ozar entre outros. 27/07/2013 – Julho (Lisboa) 21/09/2013 – Setembro (Lisboa) 19/10/2013 – Outubro (Lisboa) 23/11/2013 – Novembro (Lisboa) Reserva estes dias na agenda! :)
  38. 38. Dúvidas?

×