SlideShare a Scribd company logo

ConFoo 2017: Introduction to performance optimization of .NET web apps

•Download as PPTX, PDF•
•
P
Pierre-Luc Maheu

This document discusses performance optimization of .NET web apps. It defines performance as response time and resource utilization. It emphasizes measuring performance before and during optimization to identify the right things to optimize. A variety of tools are presented for different levels of performance monitoring and profiling, including Application Performance Monitoring, lightweight code profilers, and code profilers for highest detail. Best practices like leveraging load balancers and avoiding implicit transactions are also recommended.

1 of 24
Introduction to Performance Optimization of .NET web apps
About me  Developer/DevOps at Amilia  Optimization, scaling, monitoring, SQL Server, Elastic Search  Editor at InfoQ.com, writing about .NET and F#  @plmaheu
In this talk  What does “performance optimization” mean?  Tools of the trade  Focused on the server side
What does “performance” means?  Depends on how it is measured.  What interest us is response time (measured in ms) and resource utilisation (CPU, memory, disk, bandwidth)
The method everybody knows: Guessing  Tempting to try to optimize code out of a gut feeling  Unlikely to get it right more than 5-10% of the time  The possible causes are endless: code, third party library, web server, CDN, DNS, bandwitdh, ISP, hardware, etc.
Ahmdal’s law 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. TL;DR: Optimize the right thing.
That SQL query is slow. So what?
Time to optimize  Measure everything, all the time. Knowing precisely what is slow is key to efficient performance optimization.  Stopping profiling too early and fixing the wrong problem is an easy trap to fall into.
Optimize what?  Optimizing the the right thing: trickier than it sounds  Libraries often have overhead on first call (razor view compilation, scanning an object with reflection, data caching, library caching.  SQL queries: Parametrized queries, locks, data not in cache  Tip: Run your request a few times times to get consistent timings.
Not all bottlenecks are created equals  Different application types lead to different bottlenecks  Uncommon performance issues in unoptimized code:  Garbage Collection  Hitting concurrent request limit, default in asp.net is 12 * cores (async)  Minor innefficiencies like an extra if condition
Different issues at different scales. 1s Upload a file to third party cloud service 10ms to100ms SQL Queries 1ms Regex match 0,001ms Get a property through reflection 0,000,001ms Multiplying two numbers together A file upload may look slow, but a thousand SQL queries is slower.
Tooling
Some numbers: Amilia  2 million pageviews per month  Between 10 to 20 million requests per month  Usual throughput : 300 to 500 requests per minute  During registrations: Anywhere from 1,000 to 12,000 rpm  SQL: 100,000+ queries per minute in peaks  Avg. execution time: 100 ms Note: Static files (js, css, html) are not included, served directly from CDN
Application Performance Monitoring Provides a clear picture of what’s happening in production. Data can be used as a starting point to reproduce an issue locally.  Stackify Retrace  New Relic APM  App Dynamics  Application Insights
ConFoo 2017: Introduction to performance optimization of .NET web apps
Lightweight code profilers Provide live performance data on both dev and production systems.  MiniProfiler  Glimpse  Prefix
Example: MiniProfiler
Compared to an optimized page www.amilia.com/store/en/amilia-customer- success/shop/programs/17513
Code Profilers Gives highest degree of details. Impractical for production, significant overhead.  Redgate ANTS  JetBrains dotTrace
Taken with ANTS
I/O: Third-party services and systems must be monitored, even if control over them is limited. Databases, CDN, payment processor, etc. Service Map and Database tabs in New Relic
Follow best practices  Issues can often be avoided by taking a quick look at best practices for a library  Difficult and time consuming to find Examples:  IIS and HTTPS -> Offload to a load balancer  NHibernate -> Avoid implicit transactions  SQL Server -> Too many to name them
To sum it up  Measure before, during and after changing code  Optimizing without measuring is like fixing a bug without testing  Various tools are at your disposal, each giving visibility on some level  Article with links to the tools: https://www.infoq.com/articles/dotnet- performance-monitoring-optimization
Questions?

More Related Content

ConFoo 2017: Introduction to performance optimization of .NET web apps

  • 2. About me  Developer/DevOps at Amilia  Optimization, scaling, monitoring, SQL Server, Elastic Search  Editor at InfoQ.com, writing about .NET and F#  @plmaheu
  • 3. In this talk  What does “performance optimization” mean?  Tools of the trade  Focused on the server side
  • 4. What does “performance” means?  Depends on how it is measured.  What interest us is response time (measured in ms) and resource utilisation (CPU, memory, disk, bandwidth)
  • 5. The method everybody knows: Guessing  Tempting to try to optimize code out of a gut feeling  Unlikely to get it right more than 5-10% of the time  The possible causes are endless: code, third party library, web server, CDN, DNS, bandwitdh, ISP, hardware, etc.
  • 6. Ahmdal’s law 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. TL;DR: Optimize the right thing.
  • 7. That SQL query is slow. So what?
  • 8. Time to optimize  Measure everything, all the time. Knowing precisely what is slow is key to efficient performance optimization.  Stopping profiling too early and fixing the wrong problem is an easy trap to fall into.
  • 9. Optimize what?  Optimizing the the right thing: trickier than it sounds  Libraries often have overhead on first call (razor view compilation, scanning an object with reflection, data caching, library caching.  SQL queries: Parametrized queries, locks, data not in cache  Tip: Run your request a few times times to get consistent timings.
  • 10. Not all bottlenecks are created equals  Different application types lead to different bottlenecks  Uncommon performance issues in unoptimized code:  Garbage Collection  Hitting concurrent request limit, default in asp.net is 12 * cores (async)  Minor innefficiencies like an extra if condition
  • 11. Different issues at different scales. 1s Upload a file to third party cloud service 10ms to100ms SQL Queries 1ms Regex match 0,001ms Get a property through reflection 0,000,001ms Multiplying two numbers together A file upload may look slow, but a thousand SQL queries is slower.
  • 13. Some numbers: Amilia  2 million pageviews per month  Between 10 to 20 million requests per month  Usual throughput : 300 to 500 requests per minute  During registrations: Anywhere from 1,000 to 12,000 rpm  SQL: 100,000+ queries per minute in peaks  Avg. execution time: 100 ms Note: Static files (js, css, html) are not included, served directly from CDN
  • 14. Application Performance Monitoring Provides a clear picture of what’s happening in production. Data can be used as a starting point to reproduce an issue locally.  Stackify Retrace  New Relic APM  App Dynamics  Application Insights
  • 16. Lightweight code profilers Provide live performance data on both dev and production systems.  MiniProfiler  Glimpse  Prefix
  • 18. Compared to an optimized page www.amilia.com/store/en/amilia-customer- success/shop/programs/17513
  • 19. Code Profilers Gives highest degree of details. Impractical for production, significant overhead.  Redgate ANTS  JetBrains dotTrace
  • 21. I/O: Third-party services and systems must be monitored, even if control over them is limited. Databases, CDN, payment processor, etc. Service Map and Database tabs in New Relic
  • 22. Follow best practices  Issues can often be avoided by taking a quick look at best practices for a library  Difficult and time consuming to find Examples:  IIS and HTTPS -> Offload to a load balancer  NHibernate -> Avoid implicit transactions  SQL Server -> Too many to name them
  • 23. To sum it up  Measure before, during and after changing code  Optimizing without measuring is like fixing a bug without testing  Various tools are at your disposal, each giving visibility on some level  Article with links to the tools: https://www.infoq.com/articles/dotnet- performance-monitoring-optimization

Editor's Notes

  1. Each environnement is different, this presentation being .NET is focused on the server side. Front-end has its own set of tools and challenges. A performance issue usually have multiple possible solutions, can’t make a choice without context.
  2. Memory footprint, latency, time to see a result, amount of hardware required
  3. Any small detail can make all the difference.
  4. Total : 10 seconds. Even if the query was completely removed, max improvement is 1%. No measurements, no way to know if optimization is worthwhile
  5. MiniProfiler and Glimpse -> Configuration Prefix -> Installed, works with profiler APIs