Optimizing Your Website’s

PerformanceA Session by Mitchel Sellers

About Your Speaker

Mitchel Sellers

Microsoft C# MVP, DotNetNuke MVP

CEO of IowaComputerGurus, Inc.

Contact Info

Twitter: @mitchelsellers

Blog: http://www.mitchelsellers.com

Email: msellers@iowacomputergurus.com

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

http://fiddler2.com/ - Free download

Investigate requests & responses

Examples

kcci.com > 200 HTTP Requests

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

http://tinyurl.com/nzvx5l6

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!