ASP.NET Site Performance Secrets

Chapter 1. High Level Diagnosis

Being responsible for a site with slowly loading pages is simply not good. Having twitchy managers look over your shoulder, angry phone calls from advertisers, and other such nastiness is simply no fun. Unfortunately, it can happen to even the best developer"one day your site is cruising along just fine and the next morning, it is really slow. Of course, it may not be completely your fault. Moving the site to that cheap hosting plan may have a bearing on it, or the advertising campaign that marketing just launched without telling you, driving massive traffic to the site. In the end, it doesn't matter"all eyes are on you to make the site faster, and do it quickly. Of course, if you slip in performance improvements in regular releases, there is a better chance you'll avert that sort of crisis.

The problem is that generating even a moderately complex web page involves many lines of code and many different files. Seeing that time is always short, you'll want to zero in on those lines of code and those files that have the biggest impact on performance, leaving everything else for another day. Do this in a structured, top-down way, and you'll get it done more quickly and with a greater chance of success.

In this chapter, you'll learn the following:

The overall process of assuring good performance, and how performance tuning fits into this.
How to generate Waterfall charts as a way to identify those aspects of your site that cause web page performance issues.
A number of scenarios of poor performance and how to recognize each scenario using the Waterfall charts you generated. With each scenario, you'll find a reference to the specific chapter that shows how to further pinpoint the bottleneck, and then eliminate it.

In this chapter, we'll stay at a fairly general level; in the subsequent chapters, we'll dive deeply into the technical aspects of improving your website's performance. This will include performance monitoring (Chapter 2, Reducing Time to First Byte), IIS thread usage (Chapter 6, Thread Usage), database access (Chapter 8, Speeding up Database Access), and on-the-fly JavaScript compression and on-demand loading (Chapter 13,

To see how to load test your code without touching your production environment, refer to Chapter 14,

Assuring good performance

Before you start diagnosing and fixing performance issues, let's first have a quick look at how this fits in to the overall process of assuring good performance. This process consists of these parts:

Continuous monitoring
Setting performance goals
Iterative improvements

Let's go through each part of the process one-by-one.

Continuous monitoring

The performance of your website is affected by both the things you control, such as code changes, and the things you cannot control such as increases in the number of visitors or server problems. Because of this, it makes sense to monitor the performance of your site continuously. That way, you find out that the site is becoming too slow before your manager does.

At the end of this section, you'll find a list of monitoring services that will keep an eye on your site.

What do you mean by "site is becoming too slow"? Glad you asked.

Setting performance goals

When this books talks about performance, it ultimately talks about page load time that's what your visitors and potential customers experience.

It pays to have a clear understanding of how fast is fast enough. Spending time and effort on making your site faster is time and effort not spent on other improvements. There is little point in making your site faster if it is already fast enough.

Your manager, client, or marketing department may have ideas about what constitutes "fast enough". Alternatively, visit the page Website Response Times at http://www.useit.com/alertbox/response-times.html to gain inspiration for setting performance goals.

Ok, you've been monitoring your site, and found it is getting too slow. What now?

Iterative improvements

Because websites, web servers, and browsers are such complex beasts, it pays to make improvements in a deliberate fashion. Hence, these two golden rules:

One change at a time: Because multiple changes can affect each other in surprising ways, life will be much easier if you implement and evaluate changes one-by-one.
Test, test, test: You don't know whether your change really is an improvement until you have tested it thoroughly. Make sure that performance after the change is better than performance before the change, and be ready to roll back your changes if it isn't; what works for other sites may not work for your site.

This process makes your site run faster. An iterative process is shown as following:

1. Record the current performance.
2. Diagnose the performance problem identify the single most important bottleneck.
3. Fix that one bottleneck (remember, one change at a time).

4. Test your change. Has performance improved? If it didn't, roll back your change and come up with a better fix. If it did, go back to step 1.

As a result of this, making your site faster is an iterative process:

If you find bottlenecks that currently do not pose a problem, but will come back to bite you in the future, it may be good to fix them, now that they are clear in your head.

We can capture all this in a flowchart:

Monitoring services

If you search Google for "site monitoring service", you'll find lots of companies that will monitor your website's performance for you. They also alert you when the response time gets too high, indicating your site is down.

Here are a few of the monitoring services that offer a free plan at the time of this writing. Note that the descriptions below relate to the free plan. If you are prepared to spend a bit of money, check their websites for their offerings:

Pingdom:
Pages you can monitor: 1
Checking frequency: Once every 1, 5, 15, 30, or 60 minutes
Checks from: United States, Asia, Europe
Sends alerts via: E-mail, SMS, Twitter or iPhone
Reporting: Detailed downloadable stats showing the result of each check
Mon.itor.us:
Pages you can monitor: Unlimited (1 per contact e-mail address)
Checking frequency: Once every 30 minutes
Checks from: United States, Europe
Sends alerts via: E-mail, SMS, Twitter, or IM
Reporting: Weekly reports, real-time graph
dotcom-monitor:
Free 30-day trial
Pages you can monitor: Unlimited
Checking frequency: Once per minute
Checks from: United States, Europe, Israel
Sends alerts via: E-mail, Phone, SMS, Pager, SNMP
Reporting: Daily, weekly, and monthly e-mails, extensive online reports, and graphs
247webmonitoring:
Pages you can monitor: 5
Checking frequency: Once every 15, 30, or 60 minutes
Checks from: United States
Sends alerts via: E-mail
Reporting: Real-time graph

Now that we've seen the process of assuring satisfactory performance, let's focus on how to diagnose and fix performance problems. After all, that is what this book is all about.

Assuring good performance

Before you start diagnosing and fixing performance issues, let's first have a quick look at how this fits in to the overall process of assuring good performance. This process consists of these parts:

Continuous monitoring
Setting performance goals
Iterative improvements

Let's go through each part of the process one-by-one.

Continuous monitoring

At the end of this section, you'll find a list of monitoring services that will keep an eye on your site.

What do you mean by "site is becoming too slow"? Glad you asked.

Setting performance goals

When this books talks about performance, it ultimately talks about page load time that's what your visitors and potential customers experience.

Ok, you've been monitoring your site, and found it is getting too slow. What now?

Iterative improvements

Because websites, web servers, and browsers are such complex beasts, it pays to make improvements in a deliberate fashion. Hence, these two golden rules:

One change at a time: Because multiple changes can affect each other in surprising ways, life will be much easier if you implement and evaluate changes one-by-one.
Test, test, test: You don't know whether your change really is an improvement until you have tested it thoroughly. Make sure that performance after the change is better than performance before the change, and be ready to roll back your changes if it isn't; what works for other sites may not work for your site.

This process makes your site run faster. An iterative process is shown as following:

1. Record the current performance.
2. Diagnose the performance problem identify the single most important bottleneck.
3. Fix that one bottleneck (remember, one change at a time).

4. Test your change. Has performance improved? If it didn't, roll back your change and come up with a better fix. If it did, go back to step 1.

As a result of this, making your site faster is an iterative process:

If you find bottlenecks that currently do not pose a problem, but will come back to bite you in the future, it may be good to fix them, now that they are clear in your head.

We can capture all this in a flowchart:

Monitoring services

Pingdom:
Pages you can monitor: 1
Checking frequency: Once every 1, 5, 15, 30, or 60 minutes
Checks from: United States, Asia, Europe
Sends alerts via: E-mail, SMS, Twitter or iPhone
Reporting: Detailed downloadable stats showing the result of each check
Mon.itor.us:
Pages you can monitor: Unlimited (1 per contact e-mail address)
Checking frequency: Once every 30 minutes
Checks from: United States, Europe
Sends alerts via: E-mail, SMS, Twitter, or IM
Reporting: Weekly reports, real-time graph
dotcom-monitor:
Free 30-day trial
Pages you can monitor: Unlimited
Checking frequency: Once per minute
Checks from: United States, Europe, Israel
Sends alerts via: E-mail, Phone, SMS, Pager, SNMP
Reporting: Daily, weekly, and monthly e-mails, extensive online reports, and graphs
247webmonitoring:
Pages you can monitor: 5
Checking frequency: Once every 15, 30, or 60 minutes
Checks from: United States
Sends alerts via: E-mail
Reporting: Real-time graph

Now that we've seen the process of assuring satisfactory performance, let's focus on how to diagnose and fix performance problems. After all, that is what this book is all about.

Creating a Waterfall chart using Firebug

There are many free tools that will generate a Waterfall chart for you. One of those is Firebug, the popular add-on for the Firefox browser. Obviously, this tool works only for Firefox and not Internet Explorer or other browsers; so at the end of this chapter, you'll find other free tools that generate Waterfall charts for those browsers. But given the popularity of Firebug, we'll stick with that for now.

Installing Firebug

To use Firebug, you need to have the Firefox browser installed on your computer. Get it for free at http://www.mozilla.com/.

Once you have Firefox running, use it to open the Firebug home page at http://getfirebug.com/.

Here you'll find a link that installs Firebug.

Creating the Waterfall chart

Now that you have Firebug installed, create a Waterfall chart:

1. In Firefox, open the Tools menu, choose Firebug, and then choose Open Firebug or press F12. The Firebug bar appears at the bottom of the browser window.
2. In the Firebug bar, click on the Net drop-down and select Enable. Also, make sure that the All option is selected below the Firebug bar.

3. Browse to a page in Firefox. You will see the Waterfall chart of the various components on the page appear.

Interpreting the Waterfall chart

That chart is certainly very colorful, but what does it all mean? Actually, Firebug provides a lot of information in the Waterfall chart, including full request and response headers and timeline information. Also, it's easy to save all this information to a file.

Request and response information

Click the little + sign to the left of a filename in the Waterfall chart. You'll see a drop-down with the full request and response headers that were sent when the file was retrieved.

But wait, there is more:

In the drop-down, click on the Response tab to see the contents of the file.
If the URL of the file had query string parameters, they are shown in a Params tab.
If this was a POST or PUT request, there is a tab with the sent data.
If it is an HTML file, the HTML tab shows the actual page created by the HTML, which is very handy for iframes.
If the response came in the form of a JSON file, you'll find a tab with the data in the form of an expandable tree. For more information about JSON, visit http://www.json.org/.

Timeline information

Hover the mouse over a colored bar to see detailed timing information:

Here is what the numbers mean:

DNS Lookup	Time taken to find the IP address of the server holding the file, based on the file's URL.
Connecting	Time spent creating a TCP connection.
Queuing	Firefox limits the number of outstanding requests. If it finds an image or some other file in the `.aspx` page while Firefox is already at the maximum number of outstanding requests, it queues this new file. Queuing shows the time spent by the file in this queue.
Waiting For Response	Time spent waiting for the first byte of the file from the server.
Receiving Data	Time spent in receiving the file.
'DOMContentLoaded' (event)	Time between the start of the DNS lookup of this request and the entire DOM (Document Object Model) being ready. The DOM is the browser's internal representation of the HTML on your page. When the DOM is ready, the visitor can look around the entire page, even while some items are still loading. This number can be negative if the request started after the DOM became ready.
'load' (event)	Time between the start of the DNS lookup of this request and the page having been fully loaded, including the images.

In addition to this timing popup, there are two more. Hover over the file size to see the precise size of the file in bytes. To see the full URL of a file, hover over its name.

Page-level information

At the very bottom of the Waterfall chart, you will find the total number of files making up the page, their total size and the total page-load time:

Saving information

To save the headers to the clipboard, right-click on a file to get a popup with a save option. You can then paste the headers to a text file.

To save the entire chart to a file, use the NetExport extension for Firebug available at http://getfirebug.com/releases/extensions.html.

Once you have this installed, an Export button appears above the Waterfall chart, next to the All button. This exports the chart to a .har file.

If you open the .har file in your favorite text editor, you'll find that the file stores the information in JSON format.

The easiest way to view your .har files as a chart is with the online viewer at http://www.softwareishard.com/har/viewer/.

This not only shows the Waterfall chart saved in the .har file, but also throws in some additional statistics:

How much of the total wait time was taken by the various components of each request (DNS lookup, receiving the page, and so on)
The proportion of the total page weight in bytes taken by the .aspx file, images, CSS files, and so on
The proportion of the total page weight that came from the internal browser cache rather than over the Internet
The size of the request and response headers as compared to the request and response bodies

Categorizing bottlenecks using Waterfall charts

Before we saw how to create a Waterfall chart with Firebug, we discussed the four broad categories of bottlenecks that slow down page loading:

Main .aspx file taking too long to generate
Main .aspx file taking too long to load
Images (and flash files) taking too long to load
JavaScript and CSS files blocking page rendering

The following sections show how each broad category expresses itself in a Waterfall chart generated by Firebug. Each section also refers you to the chapter where you'll see how to further pinpoint the bottleneck and then fix it.

Scenario 1: Main .aspx file takes long to arrive

In the chart below, the top line is for the main .aspx page. The purple section shows how long the browser waited until it received the first byte. It shows a situation where the browser has to wait a long time for the first byte of the .aspx file. Obviously, this delays loading of all other components, because it is the .aspx file that tells the browser which images, CSS files, and so on to load.

If your web page produces a similar Waterfall chart, you will want to focus on reducing the time it takes the web server to generate the .aspx page. Refer to Chapter 2, Reducing Time to First Byte, where you'll see how to pinpoint web server issues, code issues, and so on.

Scenario 2: Main .aspx file takes long to load over the Internet

In the chart below, the top line still refers to the .aspx file. In this scenario, the purple section shows that the browser didn't have to wait long for the first byte of the .aspx file. However, the grey section shows it took a long time to load the entire file over the Internet. This, in turn, delays loading of those images and other files that appear towards the end of the .aspx file.

To see how to deal with this scenario, refer to Chapter 9,

Scenario 3: Images take long to load

This chart shows a common scenario, where the .aspx file is quick to arrive and load, but the images on the page take a long time to load. Fortunately, browsers will load a number of images in parallel rather than one-by-one, speeding up the process. However, the number of images loaded in parallel is limited by the browser to avoid overloading the connection; the exact limit depends on the browser. As a result, on pages with lots of images, some images will wait for other images to load first, thereby increasing the page load time, as shown in the following screenshot:

Refer to Chapter 12, Reducing Image Load Times to see how to get your images loaded sooner in a variety of ways, including browser caching and removing unused bytes to reduce image file sizes.

Scenario 4: JavaScript file blocks rendering

This chart shows a less common scenario, where a JavaScript file blocks rendering of the rest of the page. This can have a big impact on overall page load time.

When an external JavaScript file starts loading, rendering of the rest of the page is stopped until the file has completed loading and executing. This ensures that the JavaScript coming later in the page can use JavaScript libraries that were loaded and executed earlier on. CSS files also block page rendering in order to ensure that the visitor is not exposed to the raw , unstyled version of the page.

The following chart shows a different scenario where JavaScript code blocks rendering of the rest of the page, not by being slow to load but by taking a long time to execute. This could be caused by both external JavaScript, which is loaded from an external file, and by internal JavaScript which sits in the main .aspx file.

Solutions for this scenario include reducing the download time of JavaScript files, loading them after the page has been rendered, and loading them on demand. Chapter 13, Improving JavaScript Loading goes into the details. It also shows how to improve loading of your CSS files, and how to ensure that the advertisements served by external advertisement networks do not block rendering of your page.

Waterfall generators for other browsers

The Waterfall chart generated by Firebug as introduced earlier in this chapter obviously only works with Firefox, because Firebug is a Firefox add-on. This is not convenient if Firefox is not your favorite browser, or if you want to see how other browsers load content. Here are a few free alternatives for other browsers.

Fiddler (browser-independent)

Fiddler is a proxy which logs all HTTP and HTTPS traffic between your browser and the Internet. It also allows you to change the incoming and outgoing data. Because it doesn't integrate with the browser itself as Firebug does, Fiddler works with any browser, including Internet Explorer.

Download at Fiddler from http://www.fiddler2.com/fiddler2/.

To generate a Waterfall chart with Fiddler, follow these steps:

1. Start Fiddler.
2. Make sure that the Streaming button is depressed. This ensures that Fiddler doesn't use buffering, which would distort the Waterfall chart.

3. Start your favorite browser and load a page. It is the easiest if you have only one page open at a time, because Fiddler will record all traffic to all browser windows.
4. You will see all the files loaded as part of the page in Fiddler, in the left-hand Web Sessions window.
5. Press F12 to stop capturing any more traffic.
6. From the Edit menu, choose Select All. This way, all files will be shown in the Waterfall chart.
7. Click on the Timeline tab on the right-hand side. This will show the Waterfall chart. To see how to interpret the chart, visit http://www.fiddler2.com/fiddler/help/timeline.asp.
If the bars on the timeline look hatched rather than solid, it means that Fiddler has used buffering, which distorted the chart. Click on the Streaming button to switch off buffering and start again.

8. If you want to analyze another page, clear out the Web Sessions window first by clicking on the Remove button. Press F12 again to start capturing traffic again and visit another page in your browser.

Internet Explorer via WebPagetest

This free, web-based service uses Internet Explorer to produce Waterfall charts. Simply visit their site at http://www.webpagetest.org/test and enter the URL of a page you're interested in. You can run tests from the United States, the UK, and New Zealand.

Because this is a web-based service, there is no software to install. On the other hand, it won't work for you if your site is behind a firewall, which probably applies to your development server.

Also, keep in mind that it runs Internet Explorer to produce its charts, so the charts you see apply to that browser even if you are visiting WebPagetest with Firefox!

Google Chrome

Google's Chrome browser lets you generate a simple Waterfall chart right out of the box. You also get headers and other details about each file.

Download Google Chrome fromhttp://www.google.com/chrome.

To generate a Waterfall chart:

1. Open a web page in Chrome.
2. Right-click anywhere on the page and choose Inspect element. The Web Inspector window appears.
3. In the new window, click on the Resources button.

4. Choose to enable Resource Tracking. Your page reloads and the Waterfall chart appears.

To see request and response headers, parameters, and so on, click on a filename to the left of the Waterfall chart. This replaces the Waterfall chart with detailed information for that file.

Apple Safari

Apple Safari has the same underlying code base as Google Chrome, including the Web Inspector.

Download Apple Safari from http://www.apple.com/safari/.

However, before you can use the Web Inspector on Safari, it needs to be enabled first:

1. Open Safari.
2. Open the Safari settings menu and choose Preferences. The Preferences popup appears:

3. Check Show Develop menu in menu bar.

4. Close the Preferences popup.

With the Web Inspector enabled, you can now generate a Waterfall chart in the same way, as with Google Chrome:

1. Open a web page in Safari.
2. Right-click anywhere on the page and choose Inspect element. The Web Inspector window appears.
3. In the new window, click on the Resources button.

4. Choose to enable Resource Tracking. Your page reloads and the Waterfall chart appears.

To see request and response headers, parametes, and so on, click on a filename to the left of the Waterfall chart. This replaces the Waterfall chart with detailed information for that file.

Filter reviews by

All

Amazon verified reviews

Goodstuff Appreciator Oct 01, 2011

Term "ASP.NET performance" returns more than 60,000 results on Google search. If you need to learn how to develop fast ASP.NET websites, it's easy to get lost in the ocean of articles, instructions, and blogs. ASP.NET Performance Secrets makes this task much easier.The book is not just a collection of tips and secrets; it rather describes a systematic approach to optimizing websites. Book content is a workflow of the optimization process. It lists the areas that performance-minded developers need to bear in mind to improve speed of webpages.It starts from diagnostic, then goes into areas such as optimizing memory, CPU, caching, and reducing time to first and last byte, and then covers more advanced topics such as threading and load testing. It also describes techniques helpful to keep any websites fast (not only ASP.net) such as optimizing javascript, images, database and compression.While beginners may want to read the entire book as a practical guide, it also can be used as a reference book. It is well organized and every chapter can be read independently. I keep this book handy and return to the chapters that I need for particular projects.

Amazon Verified review

Joseph Guadagno Mar 25, 2011

When I first got this book I thought it was going to be a compilation of tips and tricks. I was quite surprised with the fact that it really wasn't. The author starts out by telling you how you to determine the bottlenecks in your site then goes into a lot of samples on how to correct and / or improve them. He covers memory, CPU, caching, compression and more.This book is definitely worth a read then a reread every once in a while. I plan on implementing some of the suggestions for my sites.

Gomolickij Dec 08, 2022

As described.

Joe Stagner Feb 03, 2011

There are few ASP.NET Performance books out there and even fewer good ones.This one I like. Matt Perdick has taken an interesting approach by not just presenting technology tips and tricks that can be used to positively effect performance but rather presents the technologies in the context of a methodology one can use to identify and resolve performance problems in their own web applications.Matt covers the tools you can use with the bottleneck pinpointing process to find and fix issues with :*Time to First Byte*Memory Usage*CPU Consumption*Caching*Browser*Proxy*Output*IIS Output*Data*Thread usage and Asynchronous Architectures*Reducing Long Wait Times*Database Access*Time to Last Byte*Compression*Forms Optimization*JavaScript and CSS*Images*Load TestingIt's easy to read with ample code samples and screenshots and contains many, many of the kind of tips you would expect concerning things like ASP.NET View State, Element Ids, working with User Agent specifics, etc.A good addition to your ASP.NET Expertise.

Wayne O Aug 03, 2011

Many of the SQL tuning tips apply to any sort of application that runs on SQL Server. What's more the author makes it easy for regular software developers to understand especially in regards to index creation.

ASP.NET Site Performance Secrets: Simple and proven techniques to quickly speed up your ASP.NET website

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

About the author

FAQs