Optimizing Your Website’s Performance A Session by Mitchel Sellers

About Your Speaker  Mitchel Sellers  Microsoft C# MVP, DotNetNuke MVP  CEO of IowaComputerGurus, Inc.  Contact Info   Blog: 

Agenda  Disclaimer/Disclosure  Performance Diagnostic Principles  Setting the goal  Methods of Handling Performance Concerns  Creating a Performance Test Plan  Good and Bad Plan Examples  Test Environment/Where & How  Analyzing Results  How the Web Is Different  Tools & Processes

Disclaimer/Disclosure  The tools discussed in this presentation are tools that I have found helpful in my experience.  I am not being compensated for recommending/showing the tools I am showing today  I am showing tools in this talk, as they are the best & most consistent way to identify & track performance issues

Methods of Handling Performance Concerns  Proactive Performance Management  Best overall approach  Test/Retest on a regular basis throughout the process  Ensure that you take performance into consideration FIRST!  Reactive Performance Management  Less effective and can lead to chasing non-bugs  Doesn’t provide a mechanism to properly compare/validate  Emergencies are never the best way to resolve things  Best Organizational Decision?  Move to proactive after successes with reactive

Setting the Goal  Get to a consistent design strategy FIRST  What are you optimizing for?  Perceived Performance?  “It feels fast”  Score on a tool?  Yay! We got an 87 on Google Page Speed  Raw request throughput?  Specific areas or functions?  Mobile vs. Desktop?

Creating a Performance Test Plan  Develop a consistent plan for analysis  Based on user interactions not the “Developers Use”  Based on specific scenarios  Must be realistic  Ensure that your test duration is long enough, but not too long  Find the sweet spot to avoid clutter, but retain realistic testing  Watch for warm vs. cold worker processes  Can skew results  Ensure that the test itself is realistic  Don’t just test.aspx pages and neglect the other resources  Ensure that the process is REPEATABLE!

Creating a Performance Test Plan: Continued  Isolated Testing Sets  Key performance areas  Public Pages – Want fast performance  Overly heavy areas  E-Commerce Checkout – Heavy, but critical  Broad Spectrum Testing Sets  Simulate a full user interaction through your app  Helps for longer running testing  Many tools can offer a hybrid of test sets to help being realistic

Additional Test Plan Considerations If Diagnosing a specific issue  Is the issue user based?  Test with a specific user  BUT, still test other users  Is the issue possibly load related?  Test with similar load.  Sampling production is possible  Is the issue browser based?  Is the issue 100% repeatable?

Good Examples of Test Scenarios  User Reports a Problem with Viewing User Profiles  Create a test plan that isolates that functionality as it is known as a specific issue  Follow the exact flow though that the user does to bring up the profiles  Show listing of users  Select User to View  Use back or return buttons to navigate

Another Good Example  User Reports a Problem with Reporting for Specific Inputs  Create a test plan that runs the report multiple times with similar inputs  Also run with known good inputs  This allows for comparison to the good and bad of the same report

Bad Example  Users Report Random Performance Issues on Site  Randomly send a load testing tool to penetrate the application  Pushing more load than normal  Resolution?  Get more information, sit with the user if you have to

Managing a Test Environment?  Where do you test?  Can the issue be recreated on a dev environment?  Yes  Great, test on dev!  No  Further considerations need to be taken  Can you test on production?  Yes, but ideally you want to do what you can to isolate items to better test, as there is overhead  Some ASP.NET performance items can be identified in production, however, changing things to test might not be feasible

Test Environment Considerations  Make sure it is similar to the real environment  Similar CPU + RAM  Similar Disk IO processes  Similar Configurations of Servers  Similar OS Versions & Editions  If changing load or specs be aware of items approaching limits  Example: Using a dual core SQL Server box in dev and a quad core in production

Risks of Testing In Production  Load Testing  DDoS flagging of your site by hosting  Network latency/congestion  System offline  Performance Sampling  Overall system slowness

Analyzing Results  Use the data, NOT your assumptions  Be sure to look at ALL of the results!  Do they make sense?  Don’t jump to conclusions  Number 1 mistake  Make incremental changes, then re-test  Remember Middle School Science Class!  However, make sure to test all impacted areas!

How the Web Is Different  Browsers  Each have their own JS Rendering Engines  Each have their own limits on simultaneous domain requests (4-10)  HTML first then everything else  Images & Assets can bloat pages  Can overwhelm server bandwidth & restrict other stuff  External calls? Server Side?

Check the Simple Stuff First  Large images, long running JS, large ViewState  Site Load?  How to do this?  Fiddler  Google PageSpeed  Google Analytics

Tools to the Rescue: Fiddler  - Free download  Investigate requests & responses  Examples  kcci.com > 200 HTTP Requests kcci.com  CNN.com > 180 HTTP Requests  Google.com = 18 HTTP Requests  Microsoft.com = 65 HTTP Requests  DMACC.edu = 99 HTTP Requests  My.NET Sites < 15 HTTP Requests *  Use this to see where its slow!

Tools to the Rescue: Google Page Speed 

Tools to the Rescue: Google Analytics

Tools to the Rescue: Loader.io

Tools To The Rescue: LoadStorm

Digging In: Moving Past Basics  Start to look at Database & Web Server Statistics  Windows Stats &/or Perf Mon  NewRelic  ANTS Profiler  SQL Monitor  Etc

Windows Stuff?  CPU – Are you CPU Bound?  Memory – Is there ram available?  Disk Space – Do you have room?  Network Bandwidth – Is there extra?

New Relic

New Relic #2

Questions?  Go!