Remember, setting max-age correctly in the Cache-Control header can improve web performance by instructing a client’s browser to keep the object in cache and refer to it for future requests.  This will keep a user from re-downloading the object.

Check out the post here: https://blogs.msdn.com/ieinternals/archive/2010/01/26/Use-Max-Age-values-less-than-MaxInt.aspx

Permanent Redirection (ASP.NET 4)

Using Response.Redirect will cause a HTTP 302 to be returned to the client thus creating an extra HTTP request every time.  If the URL has been permanently redirected, you will be able to use the RedirectPermanent.  With this, the first request will result in an extra HTTP 301 however all future requests will automatically go to the new URL.*

RedirectPermanent("/newpath/foroldcontent.aspx");

Smart Script Loader (ASP.NET AJAX)

The client-script loader provides the following web performance enhancements to JavaScript loading

• Automatically loads all resources that are required by a script.
• Makes sure that each script is loaded only once.
• Improves performance by loading scripts in parallel and by combining scripts.
• Supports loading scripts only when they are needed (“lazy loading”).
• Supports loading third-party scripts like jQuery and your own scripts.
• Works with the Microsoft AJAX CDN

Microsoft AJAX Content Delivery Network (ASP.NET AJAX)

The Microsoft AJAX CDN allows you to reference the AJAX framework from a CDN instead of on your local site.  This means that if users are from China but your site is in Seattle, your users will download the AJAX scripts from a server close to them instead of from Seattle.  Reducing latency between the client and server goes a long way to improving web performance.

For more information check out: https://www.asp.net/ajaxLibrary/cdn.ashx

New View State Modes (ASP.NET 4)

ASP.NET view state can add an unnecessary amount of data to your web pages.  The worst part about it is that view state is sent in both  the request and responses to decrease web performance “coming and going”.  Before ASP.NET 4, view state was enabled by default for a page and all controls.  With this new feature, you are able to turn view state off at the page level and turn it on for individual ContentPlaceHolders or the control itself.

<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs"
Inherits="WebApplication1._Default"
ViewStateMode="Disabled" %>

To learn more about these features and others, check out: https://www.asp.net/LEARN/whitepapers/aspnet4/default.aspx

NOTE: These features are present in ASP.NET 4 Beta 2 and are not guaranteed to be in the RTM.

*UPDATE:  Internet Explorer will not cache the 301 result and end-users will always experience the redirect.  Firefox and Chrome will cache the result and automatically take users to the new page when the old URL is used.  This is verified on IE 8, Firefox 3.5.7 and Chrome 3.0.195.38

Fiddler version 2.2.4.5 is required.  Currently this is the BETA release on https://www.fiddler2.com/Fiddler2/version.asp

Download here: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5975da52-8ce6-48bd-9b3c-756a625024bb

Please provide any feedback you may have by emailing nexpertb@microsoft.com

A video of the presentation will be posted as soon as it is available.

The video and walkthrough goes through setting up Fiddler on the server, capturing the traffic (adding neXpert steps along the way), and then creating a VSTS web test using the Fiddler capture.

Check it out!

Post - https://blogs.msdn.com/ace_team/archive/2009/05/29/how-do-i-set-up-fiddler-s-reverse-proxy-to-create-a-vsts-2008-web-test.aspx

Video - https://msdn.microsoft.com/en-us/teamsystem/dd876614.aspx

The latest version of Fiddler (2.2.2.0) has an updated “Save As Visual Studio Web Test” which will now use any steps you created with neXpert to automatically create transactions in the generated web test.

NOTE:  You may experience a bug with the think time not correctly being set on the resulting web test.  You can easily change the think time between requests through the Visual Studio GUI.  This will be fixed in a future version of Fiddler. (This note will be updated with the version it is fixed in)

If you have never checked out the original feature, please see the following resources:

• Sean Lumley’s (VSTS Developer and creator of the feature) Tutorial On Creating a Web Test with Fiddler 
  https://blogs.msdn.com/slumley/pages/enhanced-web-test-support-in-fiddler.aspx
• Visual Studio Web Test Feature Page
  https://www.fiddlertool.com/Fiddler/help/WebTest.asp

This post will first go over the value of transactions and then provide a walkthrough of creating transactional web tests with Fiddler/neXpert

What is a Transaction?

“A transaction in a Web test is like a timer. You can encapsulate a set of actions in a transaction. You can think of a typical transaction as starting a timer, requesting a page, requesting another page, and then ending the timer. This series of actions, from start to end, constitutes a transaction.

When using Web tests in a load test, transaction response times are displayed in the transaction table of the Load Test Analyzer.” MSDN

So what does that mean exactly?  Transactions let you:

• Name steps in a scenario
• Associate requests together

All so you can get an accurate response time for each step of a common scenario.

Transactions in a Web Test

Lets look at some quick examples.  Say we want to script a web test of the neXpert blog.  Lets do the classic scenario of:

1. Navigate to the blog
2. Click on a post
3. Click on the email link
4. Click on the Known Issues page

Doing this using the VSTS recorder or Fiddler we get the following web test:

Running the test produces the following:

As you can see, each page is given it’s own timer.  This is fine for a simple site like the blog, but what about a more involved site like Facebook?

Lets look at the following simple Facebook scenario:

1. Navigate to login page
2. Log in
3. Click profile

Even though there are only 3 steps, there are 10 steps recorded by VSTS to complete the scenario

Running the web test also shows the time and statistics for all 10 (Not aggregates of the 3 steps we are interested in):

Here is where the power of transactions comes in.  Wrapping the appropriate steps in transactions now produces the following web test:

And running the web test produces the following chart:

Much better!

Transactions in a Load Test

Not only does this help with a single web test, it also helps with load testing.  Now you can view results by transaction after a load test is finished.  Facebook was “load tested” with 1 user for 30 sec.

The following is a snippet from the Load Test Summary provided at the end of a load test run.

Creating Transactional Web Tests with Fiddler/neXpert

Now that I have convinced you to use transactions, lets walk through how to use Fiddler/neXpert to create transactional web tests.

Step 1: Capture with Fiddler adding neXpert step markers along the way

Here is a screenshot of running through a typical scenario of someone visiting the neXpert blog.  Notice the step names marked in the “Step" column.

Step 2: Save as Visual Studio Web Test

Highlight all the session you wish to create a web test from, then select Save… Selected Sessions… as Visual Studio Web Test from the File menu.

Step 3: Create a new Test Project

In Visual Studio, create a new Test Project which will hold the web test.

Step 4: Add web test to project

Right click on the project name and choose Add … Existing Item.

Navigate to your saved web test.  Be sure to change the filter to the right of the File name box to “Web Test Files”

You should now see your web test in the project in the Solution Explorer.

Step 5: Run the test

Double clicking on the web test in the Solution Explorer will allow you to configure the web test.  As you can see, the step names in neXpert were used to create the name of each transaction.

Specifically their performance team made the following changes:

• Moved CSS/JS around on different servers to better support HTTP pipelining (Current browsers will download 6 objects concurrently per server)
• Improved caching of JS
• Cached scripts at CDNs
• Lazy-loaded certain objects
• Removed or reduced view state on the page
• Created a “lowband” version

Perhaps the most interesting improvement is reducing or removing the ASP.NET view state on the pages.  Although this post will not go into great detail about ASP.NET view state, it is important to note that the view state is turned on by default for each ASP.NET object on your page and that it can grow to a considerable size if not disabled.

Currently, neXpert is the only performance tool which will check for ASP.NET view state within a page as well as it’s size if present.  The ACE Performance team recommends that the view state only be 30% or less of the total page size however it is best practice to turn it off unless it is specifically needed.

To check your view state with neXpert, make sure you turn the check on in the options menu and then capture the page and run the report.  If a view state is detected, the report will show you each page along with the view state size and what percentage of the uncompressed page size it makes up.  Below is an example of a report of MSDN captured on April 20th, 2009:

For more information on ASP.NET view state, please visit Understanding ASP.NET View State

For more information about the performance impact of ASP.NET view state, please visit Patterns & Practices - Improving .NET Application Performance and Scalability - View State

Since neXpert also has buttons for enabling/disabling streaming and pinging, currently the last command issued will decide what occurs.

This release contains bug fixes, wording-changes as well as the addition of general and neXpert specific ExecAction listeners.

The main fix is for a nasty localization issue identifiable by a number parsing exception.  (Thanks to all who reported it)

Please check it out!

https://www.microsoft.com/downloads/details.aspx?familyid=5975da52-8ce6-48bd-9b3c-756a625024bb

As always, we would love to hear feedback from users (the good and the bad) so please drop us a line at nexpertb@microsoft.com

Additions:

• ExecAction listeners added.   See neXpert ExecAction Listeners post for more information.

Changes:

• Streaming Mode and Ping buttons on the neXpert tab now persist across Fiddler runs.  Both were removed from the options menu.
• Renamed "Clear Cache" button on the neXpert tab to "Clear WinINET Cache / Cookies" to properly describe it’s action
• If the “Add Step Marker Behavior” option is set to "Selected Session" neXpert will now unselect all sessions after successfully adding the step.
• Host Latency Table:
  • Name changed to “Server Info”
  • Column added for server’s IP address
• Redundant Calls Table:
  • Name changed to “Redundant Requests”
  • Help text updated.

Fixes:

• Localization issues fixed with number parsing on non en-US culture systems.
• Compression chart now includes XML files.
• Issues during the Ping now handled.
• Grammar/Spelling issues fixed in the report.
• View state issues fixed.

• CSS performance
• Optimizing symbol resolution
• JavaScript coding inefficiencies
• HTTP performance

Check out the video at https://videos.visitmix.com/MIX09/T53F