\u201cEssa p\u00e1gina \u00e9 lenta\u201d \u00e9 uma reclama\u00e7\u00e3o comum sobre web sites, especialmente desde que aplica\u00e7\u00f5es web come\u00e7aram a substituir aplica\u00e7\u00f5es desktop. Enquanto a web tr\u00e1z algumas caracter\u00edsticas desej\u00e1veis como seu acesso global, ela tamb\u00e9m tr\u00e1z sua parcela de desafios no que diz respeito a performance.<\/p>\n
Voc\u00ea pode encontrar material sobre otimiza\u00e7\u00e3o dispon\u00edvel online, muitas vezes sobre t\u00f3picos espec\u00edficos como compila\u00e7\u00e3o JIT, garbage collection<\/em>, otimiza\u00e7\u00e3o de consultas SQL, armadilhas no uso de uma ORM dentre outros. Embora seja tentador implementar uma otimiza\u00e7\u00e3o por parecer promissora, surge uma quest\u00e3o: como voc\u00ea sabe que a otimiza\u00e7\u00e3o ir\u00e1 realmente produzir bons resultados dado seu contexto?<\/p>\n \u00c9 claro que uma pe\u00e7a do quebra-cabe\u00e7as est\u00e1 faltando. N\u00f3s precisamos de uma maneira de encontrar problemas de performance, e de maneira cont\u00ednua. Dessa maneira, n\u00f3s sabemos o qu\u00ea \u00e9 lento e temos medidas concretas para apoiar-nos. Com esse conhecimento em m\u00e3os, \u00e9 ent\u00e3o poss\u00edvel determinar precisamente se as melhorias de performance s\u00e3o necess\u00e1rias e explic\u00e1-las aos nossos clientes.<\/p>\n Identificar performance de maneira precisa \u00e9 uma maneira muito mais eficiente de responder aos problemas de lentid\u00e3o encontrados. O primeiro problema \u00e9 que talvez n\u00e3o seja um problema de lentid\u00e3o para come\u00e7o de conversa. No caso de timeouts<\/em> (onde o balanceador de carga pode servir a conex\u00e3o depois de X segundos, por exemplo), \u00e9 simplesmente imposs\u00edvel distinguir entre um deadlock<\/em> e um tempo de resposta lento j\u00e1 que o resultado ser\u00e1 o mesmo, um timeout<\/em>. \u00c9 necess\u00e1rio obter dados para encontrar o real problema.<\/p>\n Para ilustrar a import\u00e2ncia de identificar problemas de performance de forma precisa, aqui v\u00e3o alguns poss\u00edveis pontos de lentid\u00e3o em uma aplica\u00e7\u00e3o web:<\/p>\n E a lista continua, dependendo da complexidade e escalabilidade que voc\u00ea tem que lidar. Como diagnosticar um problema de performance quando tantos componentes est\u00e3o em jogo? Uma palavra: dados. Voc\u00ea quer dados relevantes e significativos para tudo. Dados podem provar a culpa ou a inoc\u00eancia de um sistema envolvido em uma requisi\u00e7\u00e3o lenta.<\/p>\n Com dados em m\u00e3os, voc\u00ea pode come\u00e7ar pelo topo e ir tirando componentes fora da lista conforme prosseguir, similar a uma busca em uma \u00e1rvore ordenada. Voc\u00ea ficar\u00e1 mais pr\u00f3ximo dos detalhes e do real problema a medida que for caminhando na \u00e1rvore:<\/p>\n Conforme navegamos na \u00e1rvore, o problema vai ficando mais e mais preciso. Sendo assim, a informa\u00e7\u00e3o necess\u00e1ria para encontrar o problema deve possuir esse mesmo n\u00edvel de precis\u00e3o. Nesse ponto, ferramentas como profilers<\/em> de performance ou planos de execu\u00e7\u00e3o de consultas SQL se fazem necess\u00e1rios.<\/p>\n Vale citar a Lei de Amdahl<\/a>:<\/p>\n Regardless the magnitude of an improvement, the theoretical speedup of a task is always limited by the part of the task that cannot benefit from the improvement.<\/em><\/p><\/blockquote>\n Por exemplo, suponha que temos uma requisi\u00e7\u00e3o web tomando 100ms do processamento do servidor e 5 segundos para uma query SQL. Mesmo que voc\u00ea consiga abaixar o processamento do servidor para apenas 1 ms, a melhora \u00e9 marginal em termos de tempo de resposta, que vai de 5.1 para 5 segundos. Os 5 segundos de processamento SQL s\u00e3o onde o potencial de ganho \u00e9 maior.<\/p>\n Uma abordagem de fora para dentro, que identifica um problema de maneira cada vez mais precisa, funciona bem no caso de um problema localizado em apenas uma p\u00e1gina. Mas e aqueles que ocorrem em v\u00e1rias p\u00e1ginas? E se, por exemplo, v\u00e1rias p\u00e1ginas sofrem de forma intermitente de um tempo de resposta lento devido a um sub-sistema n\u00e3o estar conseguindo servir seus pedidos ou devido \u00e0 um antigo switch de rede no qual cada rein\u00edcio corre o risco de ser seu \u00faltimo?<\/p>\n Aqui \u00e9 onde a abordagem de monitoria focada apenas na aplica\u00e7\u00e3o mostra suas limita\u00e7\u00f5es. Nesse n\u00edvel, outras m\u00e9tricas s\u00e3o necess\u00e1rias para avaliar a sa\u00fade de cada componente do sistema, tanto no n\u00edvel de software quanto de hardware.<\/p>\n No n\u00edvel de hardware, as primeiras m\u00e1quinas que v\u00eam em mente s\u00e3o os servidores web e de banco de dados. Contudo, estas s\u00e3o apenas a ponta do iceberg. Todos os componentes de hardware devem ser identificados e monitorados: servidores, switch de rede, roteadores, balanceadores de carga, firewall, etc.<\/p>\n Tudo isso pode parecer \u00f3bvio para um administrador de sistemas, j\u00e1 que o monitoramento de hardware \u00e9 uma pr\u00e1tica comum. H\u00e1, por\u00e9m, que utiliz\u00e1-los com cautela: todas as m\u00e9tricas de hardware s\u00e3o em sua maioria in\u00fateis de um ponto de vista de performance se elas est\u00e3o separadas das m\u00e9tricas da aplica\u00e7\u00e3o. Em outras palavras, m\u00e9tricas s\u00e3o mais \u00fateis quando colocadas em contexto.<\/p>\n Por exemplo, uma m\u00e9dia de 50% de uso de CPU em um servidor de banco de dados pode ser completamente normal em alguns casos e uma bomba rel\u00f3gio em outros. Em hor\u00e1rios de pico, 50% de uso de CPU indica que ainda h\u00e1 espa\u00e7o para acomodar um tr\u00e1fego ainda maior. Se o mesmo 50% ocorre com frequ\u00eancia durante per\u00edodos ociosos, isso sugere que \u00e9 improv\u00e1vel que a aplica\u00e7\u00e3o sobreviver\u00e1 \u00e0 um s\u00fabito aumento de requisi\u00e7\u00f5es.<\/p>\n Em resumo, m\u00e9tricas de todo um sistema como CPU, mem\u00f3ria e uso de disco devem estar relacionadas \u00e0 m\u00e9tricas de aplica\u00e7\u00e3o para assegurar seu bom funcionamento. Estar apto a visualizar m\u00e9tricas de aplica\u00e7\u00e3o como o throughput<\/em> de requisi\u00e7\u00f5es e m\u00e9tricas de sistema como uso de CPU, oferece uma visualiza\u00e7\u00e3o muito mais completa do funcionamento de um sistema.<\/p>\n Ferramentas APM prov\u00eaem as opera\u00e7\u00f5es b\u00e1sicas de coleta, armazenamento e visualiza\u00e7\u00e3o de dados. Geralmente um agente fica a cargo de coletar os dados e envi\u00e1-los ao banco de dados. Utilizando a interface web, os dados podem ser visualizados atrav\u00e9s de pain\u00e9is de controle centrados nas requisi\u00e7\u00f5es web.<\/p>\n Ferramentas de APM s\u00e3o \u00fateis para:<\/p>\n Segue abaixo uma pequena lista de ferramentas APM com suporte out-of-the-box<\/em> para ASP.NET e IIS:<\/p>\n Para dar uma ideia completa, ferramentas de monitoramento de infraestrutura coletam m\u00e9tricas em n\u00edvel de m\u00e1quina. M\u00e9tricas s\u00e3o coletadas tanto em n\u00edvel de hardware quanto de software.<\/p>\n Profilers<\/em> leves d\u00e3o m\u00e9tricas de alto n\u00edvel em uma requisi\u00e7\u00e3o web em particular. Elas prov\u00eam feedback imediato ao desenvolvedor a medida que ele navega pelas p\u00e1ginas. Eles podem ser utilizados em todos os tipos de ambiente (desenvolvimento, testes, produ\u00e7\u00e3o, etc) fazendo com que eles sejam adequados para certificar de maneira r\u00e1pida a performance uma p\u00e1gina em particular.<\/p>\n A diferen\u00e7a fundamental em profilers leves sobre os profilers mais completos \u00e9 que eles n\u00e3o est\u00e3o ligados ao processo em execu\u00e7\u00e3o. Isso significa que voc\u00ea pode utiliz\u00e1-los sem maiores preocupa\u00e7\u00f5es com seu overhead<\/em>.<\/p>\n No contexto do desenvolvimento, profilers<\/em> leves prov\u00eam feedback imediato no c\u00f3digo que voc\u00ea est\u00e1 escrevendo. Isso \u00e9 particularmente \u00fatil para achar problemas como N + 1 ou um tempo de resposta lento, pois voc\u00ea sempre ter\u00e1 o tempo de resposta exibido no canto da p\u00e1gina.<\/p>\n Contadores de performance no Windows prov\u00eam m\u00e9tricas em diferentes aspectos em n\u00edvel de hardware e software. Ferramentas de monitoramento geralmente reportam alguns contadores de performance como uso de CPU e mem\u00f3ria. No entanto, alguns contadores \u00fateis como tempo de garbage collector<\/em> com frequ\u00eancia est\u00e3o ausentes. A maneira mais pr\u00e1tica de come\u00e7ar \u00e9 utilizar uma lista b\u00e1sica<\/a> e adicionar contadores relevantes conforme necess\u00e1rio.<\/p>\n \u00c9 poss\u00edvel coletar e visualizar contadores de performance em tempo real utilizando perfmon<\/a>. Integra\u00e7\u00e3o com APMs tamb\u00e9m \u00e9 poss\u00edvel na maioria dos casos, utilizando m\u00e9tricas personalizadas ou plugins.<\/p>\n A camada de persist\u00eancia \u00e9 frequentemente um gargalo devido a sua onipresen\u00e7a na maioria das aplica\u00e7\u00f5es. Ferramentas especializadas de monitoramento SQL prov\u00eam m\u00e9tricas em utiliza\u00e7\u00e3o de recursos assim como m\u00e9tricas espec\u00edficas como tempo de espera ou compila\u00e7\u00f5es por segundo, para dar alguns exemplos.<\/p>\n Voc\u00ea pode encontrar v\u00e1rios tipos de problemas assim como v\u00e1rios tipos de melhorias de performance com os dados obtidos:<\/p>\n Ferramentas de monitoramento SQL:<\/p>\n Todos os sub-sistemas precisam ser monitorados at\u00e9 certo ponto. Uma coleta e visualiza\u00e7\u00e3o de dados simples podem ser suficientes para um sistema de baixo throughput<\/em> ou sistemas de criticidade baixa. Em outros casos, eles demandam monitoramento mais avan\u00e7ado e especializado.<\/p>\n Quando uma p\u00e1gina em particular ou um trecho de c\u00f3digo s\u00e3o identificados como lentos, um profiler de c\u00f3digo prov\u00ea uma vis\u00e3o mais detalhada para identificar um problema de performance. Eles tamb\u00e9m d\u00e3o uma vis\u00e3o precisa de chamadas externas como consultas \u00e0 banco de dados e requisi\u00e7\u00f5es web.<\/p>\n Profilers<\/em>:<\/p>\n Monitorar mem\u00f3ria e m\u00e9tricas de garbage collector<\/em> s\u00e3o \u00fateis para detectar problemas em potencial. Enquanto eles mostram a presen\u00e7a de um problema, eles normalmente n\u00e3o falam onde est\u00e1. Um profiler de mem\u00f3ria \u00e9 \u00fatil quando h\u00e1 necessidade de adentrar em problemas de mem\u00f3ria ou garbage collector<\/em>.<\/p>\n Profilers:<\/p>\n Tamb\u00e9m podem aparecer problemas de performance do front-end<\/em>. Isso se tornou especialmente verdade com o surgimento de aplica\u00e7\u00f5es SPA (single page application<\/em>), onde o JavaScript reina. Todos os principais browsers trazem ferramentas de profiler<\/em> de c\u00f3digo e mem\u00f3ria embutido.<\/p>\n Ferramentas mostrando a sequ\u00eancia de eventos e requisi\u00e7\u00f5es s\u00e3o \u00fateis ao determinar com prontid\u00e3o se um problema vem do front-end<\/em> ou back-end<\/em>.<\/p>\n Ferramentas<\/p>\n Ferramentas client side<\/em> de alto n\u00edvel s\u00e3o \u00fateis no come\u00e7o da an\u00e1lise do problema de performance. Essas ferramentas podem dar uma vis\u222bao alto n\u00edvel de onde os problemas com tempo de respostas v\u00eam, al\u00e9m de dar algumas recomenda\u00e7\u00f5es. O PageSpeed Insights<\/a> do Google \u00e9 um exemplo gratuito de ferramenta.<\/p>\n A simples quantidade de fatores e ferramentas envolvidas em performance de um sistema podem assustar. Entretanto tudo pode ser resumido em uma palavra: dados. Ter uma vis\u00e3o clara e precisa de um sistema em um dado momento faz com que seja poss\u00edvel raciocinar sobre sua performance. Isso tamb\u00e9m fornece um aprendizado de momento, onde os gr\u00e1ficos e as m\u00e9tricas de performance podem te guiar at\u00e9 o que est\u00e1 impactando em seu sistema.<\/p>\n Fonte: https:\/\/www.infoq.com\/br\/articles\/dotnet-performance-monitoring-optimization<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" \u201cEssa p\u00e1gina \u00e9 lenta\u201d \u00e9 uma reclama\u00e7\u00e3o comum sobre web sites, especialmente desde que aplica\u00e7\u00f5es web come\u00e7aram a substituir aplica\u00e7\u00f5es desktop. Enquanto a web tr\u00e1z algumas caracter\u00edsticas desej\u00e1veis como seu acesso global, ela tamb\u00e9m tr\u00e1z sua parcela de desafios no que diz respeito a performance. …<\/span> Read More →<\/span><\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[201,2,15,20,184,178,200,185],"tags":[219,217,218],"class_list":["post-6301","post","type-post","status-publish","format-standard","hentry","category-net","category-net-framework","category-back-end","category-dicas","category-produtividade","category-qualidade-software","category-troubleshooting","category-visual-studio","tag-lentidao","tag-performance","tag-profile"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/6301","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/comments?post=6301"}],"version-history":[{"count":1,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/6301\/revisions"}],"predecessor-version":[{"id":6302,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/6301\/revisions\/6302"}],"wp:attachment":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/media?parent=6301"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/categories?post=6301"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/tags?post=6301"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
Problemas de infraestrutura<\/h2>\n
Ferramentas de monitoramento de performance (APM)<\/h2>\n
\n
\n
Ferramentas de monitoramento de infraestrutura<\/h2>\n
\n
Profilers leves<\/h2>\n
\n
Contadores de performance para tapar os buracos<\/h3>\n
Ferramentas SQL<\/h2>\n
\n
\n
Outros sistemas de persist\u00eancia<\/h2>\n
Profilers de c\u00f3digo<\/h2>\n
\n
Profilers de mem\u00f3ria<\/h2>\n
\n
Profiler client side<\/h2>\n
\n
Analisadores de p\u00e1gina<\/h3>\n