I’ve been working with some SharePoint applications and was wondering why I get additional PurePath’s when requesting certain SharePoint pages. It turned out that these additional PurePath’s show the additional web requests executed by the browser in order to request the embedded web resources. Here is the HTML that gets generated by the SharePoint page (or any other ASP.NET Application that uses WebResources):

Web Resources are requested via WebResource.axd

Once requested by the browser we get a PurePath triggered by the Web Request with the following Web Request Details:

Request details captured by dynaTrace

Unfortunately the encrypted resource string (passed as HTTP GET parameter) doesn’t give you any indication about which resource was actually requested. When analyzing page performance we however need to know which resources were actually requested, how often they got requested and what overhead they caused on the server.

I therefore created a Method Sensor Rule for System.Web.UI.Page.DecryptString which is responsible to decrypt the string that is sent from the browser to request the resource. By capturing the return value I can now analyze which embedded web resources are requested, how often they are requested and what their performance contribution to the overal page request is. Here is a sample PurePath that shows the actual requested embedded resource (WebForms.js).

 

Decrypted value shows which resource was actually requested

Conclusion

The more features and frameworks we use the harder it gets to keep track of what is really going on under the hood. Embedded Web Resources are a great feature in order to embed your resources in your .NET assemblies. Analyzing the performance impact however is hard if you have to work with encrypted values. The demonstrated approach in this blog is an easy way to keep track of the performance impact of web resources.

Related posts:

1. Resource Leak Detection in .NET Applications I’ve recently been working on one of my ASP.NET Sample...