Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

Talk at ConFoo 2017 in Montreal.

Published in: Software
  • Login to see the comments

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

  1. 1. Introduction to Performance Optimization of .NET web apps
  2. 2. About me  Developer/DevOps at Amilia  Optimization, scaling, monitoring, SQL Server, Elastic Search  Editor at, writing about .NET and F#  @plmaheu
  3. 3. In this talk  What does “performance optimization” mean?  Tools of the trade  Focused on the server side
  4. 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. 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. 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. 7. That SQL query is slow. So what?
  8. 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. 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. 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 is 12 * cores (async)  Minor innefficiencies like an extra if condition
  11. 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.
  12. 12. Tooling
  13. 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. 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
  15. 15. Lightweight code profilers Provide live performance data on both dev and production systems.  MiniProfiler  Glimpse  Prefix
  16. 16. Example: MiniProfiler
  17. 17. Compared to an optimized page success/shop/programs/17513
  18. 18. Code Profilers Gives highest degree of details. Impractical for production, significant overhead.  Redgate ANTS  JetBrains dotTrace
  19. 19. Taken with ANTS
  20. 20. 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
  21. 21. 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
  22. 22. 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: performance-monitoring-optimization
  23. 23. Questions?