neXpert v1.2 Released

Only a minor update for neXpert which allows it to continue to work with the latest version of Fiddler.

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

Download here: http://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

neXpert at Velocity Conference This Week

The creator of neXpert, Eric Mattingly, will be at Velocity Conference this week presenting.  If you are attending, seek him out and share your experiences with the tool!  Also check out his session on Wednesday afternoon, Creating Instant Response Time Predictions with neXpert

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

Capturing HTTP with Fiddler as a Reverse Proxy

My colleague on the ACE Performance Team, Vitaliy Konev, recently posted a blog post and video discussing how to set up Fiddler on a web server as a reverse proxy.  This is how you would capture HTTP traffic when you are not using a web browser client and you are also unable to configure the end-system to use Fiddler as a proxy.

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 - http://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 - http://msdn.microsoft.com/en-us/teamsystem/dd876614.aspx

Creating Transactional Web Tests for Visual Studio with Fiddler / neXpert

One of the best features of Fiddler when performance testing is it’s ability to save a capture as a Visual Studio Web Test.  You can then use this web test to functional test or stick it in a load test to stress test your site.

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 
  http://blogs.msdn.com/slumley/pages/enhanced-web-test-support-in-fiddler.aspx
• Visual Studio Web Test Feature Page
  http://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.

Checking ASP.NET View State Size

There is a fantastic post over at Scott Hanselman's Computer Zen where he discusses some of the performance improvements put into the newest version of MSDN.

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

neXpert ExecAction Listeners

neXpert v1.1 introduces many different ExecAction listeners for both general Fiddler actions and some neXpert specific actions.

Command	Action	Sample Usage
loadsaz filename	Load a SAZ file into Fiddler.	loadsaz c:\blog.saz
savesaz filename	Save a SAZ file of all captured traffic	savesaz c:\blog.saz
clearcookies	Clear all WinINET cookies.	clearcookies
clearcache	Clear the WinINET cache.	clearcache
enablestreaming	Turn on Fiddler streaming mode.	enablestreaming
disablestreaming	Turn off Fiddler streaming mode.	disablestreaming
enableping	Turn on neXpert ping.	enableping
disableping	Turn off neXpert ping.	disableping
addstep step name	Add a neXpert step to the last Fiddler session captured.	addstep Click profile link
createreport  filename	Create a neXpert report based on all traffic in the capture.  This command currently will not create the zip file of both the report and capture.	createreport c:\report.html

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

neXpert v1.1 Released!

A new version of neXpert (1.1) is now available on Microsoft Download Center.

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!

http://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.

neXpert mentioned in “Building High Performance Web Applications and Sites” at MIX09

John Hrvatin, a lead program manager on the Internet Explorer team, presented "Building High Performance Web Applications and Sites” at this years MIX.  In the talk he goes over many different aspects of web performance including:

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

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

Setting Up Your Environment For Performance Testing

This rundown should help when using Fiddler for performance testing to perform captures correctly the first time.  If you have any feedback or additions to this list, please send them using the “Contact Us” link in the top left corner of the web page.  Thanks to Vitaliy Konev for some of the tips.

Before any performance testing with Fiddler, be sure to review the following links:

• Fiddler PowerToy - Part 2: HTTP Performance
• Deep-Dive on Performance Measurement

Setting Up the Web Application and Network Environment

1. Remove proxy servers from the network path

   A proxy server between your client and your server(s) can and probably will distort any performance data.  With static objects (images, CSS, JS), the proxy will potentially serve the client what it has in its cache instead of requesting the objects from the web server which will change response times.  To remove a proxy server, you can either bring the servers into an isolated environment or try to hit the web server directly by modifying your HOSTS file to include the servers IP address.
   

2. Gain exclusive access to the server

   Having exclusive access guarantees you are in control and tries to get rid of any “X” factors during a performance baseline.  This goes for all server in the system, trying to judge the response time of an app while someone is load testing on the of the database servers it relies on can cause a headache and potentially produce bad data.  This is optional however since you may also be interested in how the response times of steps in a scenario differ when the server(s) are under load.
   

3. Capture using a client that is “close” to the web server

   Latency and network issues can be another “X” factor when performance testing.  By having your client 5ms or less away from the server(s), you can reduce the latency effect to almost nothing and reduce any potential network instability issues from occurring.
   

4. Verify the web server is “warmed up”

   If you have not hit the web site recently, the web server may need to warm up.  If your site gets any traffic in production, the end-user should never see this delay so you should be sure to not confuse it with the site itself being slow.  This is why, before you do any testing you should run through the scenarios one by one to not only verify that everything is functional, but to warm the web server up.

Setting Up IE

1. Be Cognizant of the IE version you are using

   Response times will differ depending on the version of IE (or any browser for that matter).  You should test using the browser that your end-users will be using.  One thing to consider is that the latest browsers (IE 8, FF 3, etc.) will *probably* yield the best performance.
   

2. Turn off “Automatically Detect LAN Settings”

   When set to automatically detect LAN settings, IE will parse through pages looking for a PAC file to use.  This can sometimes creates seemingly long response times and can ruin your capture.  You can access the LAN settings in IE by going to the Tools menu … Internet Options … Connections Tab … LAN Settings.
   
   
   

3. Set homepage to “about:blank”

   Having to delete session objects in Fiddler is an annoyance.  By setting your homepage to “nothing” you no longer have to worry about when to start Fiddler or that you will have to clear out the session list before the capture.
   

4. Create a shortcut to the initial page

   Fat fingering the initial URL can potentially ruin a capture.  Before starting, make a shortcut to the initial page in the scenario to test.  Make sure it’s the fully qualified domain name and that you append the “/” at the end of the URL if applicable.  For example, if testing Microsoft.com, make a link to http://www.microsoft.com/.
   

5. Close all instances of IE When Clearing Cache/Cookies

   To completely clear our both cache and cookies in IE you must shut down all windows if IE.
   

6. Clear IE Cache/Cookies

   This should be done after you shut down IE to create a “clean slate” for performance testing.  You can easily clear both the cache and cookies using the appropriate button on the neXpert tab within Fiddler.  Note: This screenshot is from the next version of neXpert, the button is currently labeled “Clear IE Cache” in version 1.0
   
   
   

 

Setting Up Fiddler

1. Enable HTTPS capturing

   
   If the site you are testing uses HTTPS, you must enable it in Fiddler.  To learn more about Fiddler’s HTTPS capturing, please visit http://www.fiddlertool.com/Fiddler/help/httpsdecryption.asp
   
   
   

2. Turn on “reuse connections to server” in Fiddler Options

   This options controls whether Fiddler will honor the “Connection: Keep-Alive” Header.  This should be turned on for performance testing 
   
   
   

3. Enable “Streaming Mode” with neXpert

   Since one of Fiddler’s main functions is to “fiddle” with HTTP traffic, it needs to buffer the responses.  While this is good for functional testing, it will cause bad response time data during performance testing.  To enable streaming mode and stop the buffering from occurring you can either use the checkbox in the neXpert options, use the button on the neXpert tab or right click the Fiddler timeline and select “Enable Fiddler Streaming”.  For more information about streaming mode, please check out http://www.fiddler2.com/fiddler/help/streaming.asp
   
    
   

4. Filter Only On Browser Traffic

   Fiddler provides a “quick filter” option in the lower left corner of the UI.  Setting this filer to “Web Browsers” will help to filter out potentially unwanted traffic.
   
   
   

5. Hide HTTPS CONNECTS

   HTPS CONNECT objects in Fiddler have no bearing on performance testing and are not referenced when creating the neXpert report.  You can safely hide these objects by clicking “Hide HTTPS CONNECTS” under the Rules menu in Fiddler.
   
    

Do you have tips when using Fiddler for performance testing?  If so, please post a comment or use the “Email” link and we will be sure to post them and give you the credit!

On Response Time Predictions…

The response time predictions currently bundled with neXpert are still considered “Beta”.  For applications which are already lean (10 round trips or less) they work quite well.  Once you get into complex applications with features such as multiple hosts, HTTPS and excessive JavaScript, they can break down quickly.

How They Are Created

Currently the predictions rest upon an accurate TCP model which will predict how long a file of a certain size will take to download given both latency and a loss rate.  This TCP model was tested and found to be very accurate for latencies between 25ms and 200ms.

The rest of the predictions come from logic expressing how browsers currently download objects.  The main difference is that IE 7 only makes 2 connections per host while IE 8 makes 6 per host.  Also IE 7 will halt all downloading when pulling down scripts while IE 8 will download scripts concurrently.

The TCP model, browser logic, and observed server processing time make up the current response time prediction implementation. 

What To Take Away

Right now the prediction’s accuracy depends on the makeup of your application.  If you are looking at simple, static, sites, you should find the predictions to be quite accurate.  If you work with giant/complex web applications you should probably expect to see some “funny” numbers. 

The Future

In the near future, the predictions will be tuned much more accurate.  The goal is to also have predictions for non-browser HTTP traffic such as WCF thick clients. For the next release with updated prediction we will try and provide as much test data as possible showing the improvements and accuracy against other prediction methods.

In the end, regional response time is most heavily affected by your site’s design and settings.  By running the performance report and tuning your app based on its suggestions (and having no significant backend delays) your users should have a great experience, no matter where they are located.

Introducing …. neXpert

What is it?

 neXpert is an add-on to Fiddler Web Debugger which aids in performance testing web applications.  neXpert was created to reduce the time it takes to look for performance issues with Fiddler and to create a deliverable that can be used to educate development teams.

neXpert can be downloaded here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=5975DA52-8CE6-48BD-9B3C-756A625024BB&displaylang=en

A webcast showing a demonstration of neXpert can be watched here:

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032398774&EventCategory=5&culture=en-US&CountryCode=US

What are the features?

·         Add step markers while capturing traffic to create steps or clicks in a scenario

·         Easy access buttons for performance testing with Fiddler

o   Clear Cache/Cookies

o   Enable Fiddler Streaming Mode (http://www.fiddler2.com/fiddler/help/streaming.asp)

·         Ping each host in a capture to calculate current latency

·         Create rudimentary response time predictions for different latencies and browsers (BETA)

·         Create a HTML report which checks for performance issues with the following:

o   HTTP Response Code

o   ASP.NET View State

o   Static Files

o   Large Images

o   Compression

o   Authentication

o   ETags

o   Cache Headers

o   Connection Header

o   Vary Header

o   Cookies

What resources are on the blog?

The left toolbar provides links to other performance-oriented blogs you may be interested in.

There is also a link to the “Known Issues” page which will be used to track any issues found in the most current public build.  If you have found any issues, please use the “Send Feedback…” option located in the neXpert menu in Fiddler. 

What will this blog be used for?

This blog will be used primarily for discussing neXpert and how it can be used to help performance test your web applications.  This will include such things as upcoming features, how to implement neXpert into your testing and how to fix the problems neXpert finds. This blog will also be used for discussing performance testing with Fiddler as well as general web performance issues.

You can subscribe to this blog using the syndication links on the left toolbar.  For information on how to use Outlook to subscribe to this blog, please click here: http://office.microsoft.com/en-us/help/HA101595391033.aspx

This is NOT Fiddler’s blog.  Fiddler was created by Eric Lawrence and you can find links to the official Fiddler resources including a blog on the left toolbar.

 Update: Added webcast link