Fiddler tool can be used for analyzing HTTP and HTTPS (must be enabled from within the fiddler tool) transactions. This tool is a simple to use and by following below tips you can capture and analyze the request and network traffic causing any performance issue. Also you can send the captured logs to support team to get these analyzed if needed. It enables us to inspect all HTTP traffic, set breakpoints, and dig through the incoming or outgoing data. Using fiddler we can check reason for performance bottleneck of a web page, which cookies are being sent to server or what downloaded content is marked as cacheable etc.
Installation,
Firstly you need to download and install the fiddler tool (https://www.telerik.com/download/fiddler/fiddler4 ) and follow the screen instructions to get this installed.
Enabling the traffic for https
- Open Fiddler and from the top menu click on Tools -> Options and click on the HTTPS tab
- Check the box for Decrypt HTTPS traffic and agree to any prompts to install the needed certificate for https decryption
- Select ‘Yes’ to accept and Ignore Server Certificate errors and again click on “Yes” to install the certificate and exit out of the Fiddler options.
Capture the network traffic,
Step1. Open the Fiddler and ensure that Capture traffic is selected under the File menu or press F12.
Step2. Run your application on using any of the browsers, before running this you can make sure that you do not open any other application or browse any site so that it captures the traffic for your application only. You can remove the existing session data by clicking Remove All Sessions.
Step3. After capturing the data, you can save it to an archive (*.saz)
Analyzing the captured traffic (Important facts)
1.Below are important tabs in fiddler
Statistics – Statistics about selected session. This is one most important section which has high level summary of the request and response times.
Filters – Filter out the http/https traffic logging
Inspectors – One can view/modify request/responses for security testing or general functionality testing. Inspectors can be used to modify request/response, break on requests remove caching etc.
Request Builder – create/build http request using existing previous requests
Timeline – Time map of all requests of a
Auto Responder – replay previously captured or generated traffic when network connection is down during demo etc.
2.Various HTTP status codes and their meaning
200 – The request has succeeded
204 – The server has fulfilled the request but does not need to return an entity-body
206 – The server has fulfilled the partial GET request for the resource and response and must include the header
301 – Moved Permanently
302 – Found, The requested resource resides temporarily under a different URI
303 – The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource
307 – The requested resource resides temporarily under a different URI
304 – If the client has performed a conditional GET request (If-Modified-Since, If-None-Match) and access is allowed, but the document has not been modified, the server should respond with this status code.
401 – The request requires user authentication
3.Two key factors in improving the speed of your Web applications
- Try reducing the number of request/response round trips –
- Try reducing the number of bytes transferred between the server and the client
HTTP caching is of the best ways to reduce round trips and bytes transferred. To enhance performance, Microsoft Internet Explorer and other Web clients maintain a local cache of resources downloaded from remote Web servers. When a resource is needed by the client, there are three possible actions
- Send a plain HTTP request to the remote Web server asking for a resource
- Send a conditional HTTP request to the origin server asking for the resource only if it differs from the locally cached version
- Use a locally cached version of the resource, if a cached copy is available
We need to control request/response cache headers for better performance
Cache-Related Request Headers – Pragma: no-cache, If-Modified-Since: datetime, If-None-Match: etagvalue
Cache-Related Response Headers – Generally, the cacheability of an HTTP response is controlled by headers sent in the response. The optional Cache-Control and Expires headers are the primary mechanisms for a Web server to indicate to a proxy or a client how content may be cached. Expires header contains date or 0 or -1. Cache-Control Header contains public, private, no-cache, no-store, max-age:#seconds, must-revalidate.