Find Performance Issues Locally

So you've Troubleshooted Performance Issues on your Website and you've determined they are related to the website application.

This guide will walk you through how you can test the site locally and pinpoint which pages are slower than others so you can drill down to each module and identify issues.

Step 1: Run in Development Mode or Live Mode

The first thing you'll need to do is determine whether you are going to test using the latest content from Agility (in Development Mode), or you want to more closely mimic the production environment and use only published content (Live Mode).

Run in Development Mode

You can run your website locally with DevelopmentMode=True set in the web.config. This will pull-down the latest content which is likely different than what is on your production website. It will also result in slower page loads across the board because the website is calling home to get new content. This method should only be used if you don't have access to a copy of the Live Content files (for published content only). Output caching is turned OFF by default. 

Note: The first time you access a page locally, the page load will be slower than subsequent calls since it will do a delta and pull the latest content. Requesting the same page again will give you faster page load times since you already have the latest content.

Run in Live Mode

In order for this method to work, you will need a copy of the Live Content files. If you have access to the web server, this can be retrieved from the ContentCacheFilePath under the Live folder. Make sure you have copied the Live content files to your local ContentCacheFilePath as specified in your local web.config. 

i.e. C:/AgilityContent/{websitename}/Live

You can now run your website locally with DevelopmentMode=False set in the web.config. If you get a 404 response, double-check that your Live content files have been copied to the correct location.

Note: If you make changes in the Content Manager, these changes will not be reflected in your local environment. You would need to refresh the Live content files manually.

Next, by default Output Cache is now enabled in the application. This can make testing pages difficult since pages will be returned from memory after they've been executed once. For example, if you had a break-point in your code, it would only get hit once until it is removed from cache and the page is processed again.

You need to temporarily disable the Output Cache in code within the global.asax.cs.

Modify this code:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    /*
		* Handle OutputCache
		* AgilityCacheControl is a special "VaryByCustom" value that is added in the Agility Controller
		*/

    if (string.Compare(custom, "AgilityCacheControl", StringComparison.OrdinalIgnoreCase) == 0)
    {
        string s = Agility.Web.Data.GetAgilityVaryByCustomString(context);

        s = string.Format("{0}.{1}", s, context.Request.Url.AbsoluteUri);

        return s;
    }

    return base.GetVaryByCustomString(context, custom);
}  

 

To this code:

public override string GetVaryByCustomString(HttpContext context, string custom)
{
    /*
		* Handle OutputCache
		* AgilityCacheControl is a special "VaryByCustom" value that is added in the Agility Controller
		*/

    if (string.Compare(custom, "AgilityCacheControl", StringComparison.OrdinalIgnoreCase) == 0)
    {
        string s = Agility.Web.Data.GetAgilityVaryByCustomString(context);

        //HACK: disable output cache
        //s = string.Format("{0}.{1}", s, context.Request.Url.AbsoluteUri);
        s = string.Format("{0}.{1}", s, DateTime.Now.Ticks);
        return s;
    }

    return base.GetVaryByCustomString(context, custom);
}

Note: Don't forget to revert this code when you are done.

Test if your pages are being output cached by placing a break-point in your code and verify it is being hit on each request.

 

Step 2: Establish a Baseline (Blank Template)

In order to find performance issues, you need to establish a baseline to compare your page load times.

The best way to do this is to create a page template that has NO header or footer on it. Essentially, you want to have a blank page so you can measure your baseline performance. 

You can use the developer tools of your favorite browser to record the page load time.

Step 3: Test Shared Components (Template with Header/Footer)

Now that you have a baseline for a blank page, add another page that uses a template with header. How does the page load time increased by rendering the header? 

How does it increase when rendering the footer?

This is an effective way to establish whether there is a performance issue with shared components of the site.

Step 4: Test a Suspect Page

At this point, you may have an idea of specific pages that may have a performance issue. Test those page load response times and see how they compare to your baseline.

Step 5: Isolate Modules on Test Page

In the previous step, you may have found a page with a high load time compared to your baseline. Now, you can remove each module one by one to isolate the module that could be causing the issue and retesting the page until you've found the culprit.

Note, if you are running in Live Mode with a copy of the content files, you would need to publish this change and re-download the Live Content files. One way to get around that, is to simply comment out the code in the modules being used one-by-one.

Step 6: Repeat with other Pages

Repeat steps 4-5 for all suspect pages, or perhaps ALL pages if you don't know which ones are having the issues.

Step 7: Implement a Fix

Once you've identified which module is responsible for slow page load time, look to implement a fix that will solve the underlying problem. Adding additional memory-based only caching will only mask the problem.

Things to consider:

• If you are doing a heavy computational task, consider how you can refactor the logic or use queues to have an offline service do this such as a Web Job or server-less function
  
  
• If you are accessing a slow, volatile third-party resource resource, consider adding file-backed caching - Accessing Volatile Resources