Most modern websites are made up of resources delivered from dozens of different servers around the web. Resources from Content-Delivery-Networks (CDNs), Web API endpoints, script frameworks, ad networks, and content management systems are all brought together on the client to build the page that the user sees.
Unfortunately, this amalgamation process can fail miserably if one of the servers involved is slow or unresponsive. Affected pages might never render, display unintelligible errors, or take so long to load that your visitors may choose to leave before your site even loads. Resources that can cause your page to fail are known as a Single Point of Failure (SPOF).
Fiddler’s AutoResponder makes it easy to test how your site behaves when any of its constituent resources is slow or unavailable. With the AutoResponder, you can selectively choose resources to delay or fail, and ensure that your client-side experience recovers as best it can.
To get started, activate Fiddler’s AutoResponder tab and tick all three boxes at the top:
Next, you’ll want to identify one or more resources to interfere with. Click the Add Rule button, and edit the newly created rule:
In the Request URL Pattern box, you can use a simple string match or a more complicated regular expression. In our case, we’ll match any requests with a URL containing the string doubleclick.net. Next, in the Action box, we’ll select which action to take when a matching request is seen.
When performing “Single Point of Failure” testing, some common choices for the Action include:
|*drop||Aborts the request, sending a TCP/IP FIN to the client.|
|*reset||Aborts the request, sending a TCP/IP RST to the client.|
|*delay:5000||Delay the request by 5 seconds, but allow it to proceed.|
|404_Plain.dat||Send a HTTP/404 response to the client.|
|502_Unreachable.dat||Send a HTTP/502 response to the client.|
For this demo, we’ll use the *reset Action:
After selecting Action, be sure to click the Save button.
By default, Fiddler will immediately take the Action when a matching request is received. However, real-world server failures are rarely instantaneous; for instance, if a server is unreachable, it often takes 21 seconds for the client to become aware of that fact. You can introduce a delay in your rule by right-clicking it and choosing the Set Latency command.
For our demo, we’ll add five seconds of latency before the connection is reset:
Now, load a page that contains some of the target resources and observe how it behaves. On our simple test page, the loading indicator spins for 5 seconds before the requests fail and the page load is complete (except for the failed advertisement):
Fiddler renders the entries for the blocked resources using a lavender background:
If each of your third-party resources guarantees 99% uptime, your overall page only has 74% chance of loading fully if it has 30 resources that act as a SPOF. Fiddler makes it easy to experience the effects of random failures by using the % operator in the pattern box. The following rule will match a random 5% of the requests whose url contains the characters .js:
You can configure each rule to match between 0 and 100% of the time. Because rules with a *delay action are treated as “non-final”, you can create a set of rules that randomly delay resources at different rates. For instance, the following rules:
After you’ve created a set of rules that you’ve found are a good test case for your site, you can right-click the list of rules and choose Export All…. The resulting .farx file may be reloaded into the AutoResponder at any time using the Import… button at the top of the tab.
Subscribe to be the first to get our expert-written articles and tutorials for developers!