What Sauce Connect does to your test traffic

 

Sauce Connect is our easy, secure tool for testing internal-only sites.  It allows developers & testers to keep the app they're working on away from the eyes of the world, while still testing it with Sauce Labs' service.

When a job uses Sauce Connect (which I'll shorten to SC from now on), every piece of data sent and received by the Sauce Labs browser is sent via the SC server, to the SC client in your network, and from there to its ultimate destination.

This is great for traffic that comes from servers in your network, but what about traffic from other locations?  Your app may be using pictures hosted on a CDN, marketing tools hosted by another company, remote error detection or logging, and a host of other services (see the examples below).  I'll be calling these external resources.

All of these external resources are also loaded through your SC tunnel.  This adds time to your tests in multiple ways, so if you can avoid it, your tests will run faster.

 

Example

 

No External Resources

 

Your tests run against an app called PhotoManagerWizard, PMW for short.  The development version of PhotoManagerWizard is hosted inside your corporate network, on DevHost01.

Your tests run from a CI server called CIHost01.  You also have Sauce Connect running on CIHost01.

The index page of PhotoManagerWizard contains some CSS, some HTML and an image.

When you ask a Sauce Labs Job to open the front page of PhotoManagerWizard, Selenium instructs the browser to load that page.  The browser reads the HTML, sees that it contains CSS and an image and fetches them as well.  It has to make every request through the SC Server:

 

GET DevHost01/index.html      => (SC Server [1ms])  => (SC on CIHost01 [20ms]) => (DevHost01 [5ms]) [26ms total]
 * GET DevHost01/style.css => (SC Server [1ms]) => (SC on CIHost01 [20ms]) => (DevHost01 [5ms]) [26ms total] * GET DevHost01/photo.jpg => (SC Server [1ms]) => (SC on CIHost01 [20ms]) => (DevHost01 [5ms]) [26ms total] TOTAL FOR PAGE: 52ms.

The browser has to load the HTML first; Once it's done so, it knows what else it needs to load and can request them at the same time.  So, the page takes 26ms to load html, then another 26ms to load the css and images.

 

With External Resources

 

What happens if, instead of loading images from DevHost01, PMW loads all images from a content host online?

 

GET DevHost01/index.html      => (SC Server [1ms])  => (SC on CIHost01 [20ms]) => (DevHost01 [5ms]) [26ms total]
 * GET DevHost01/style.css => (SC Server [1ms]) => (SC on CIHost01 [20ms]) => (DevHost01 [5ms]) [26 ms total] * GET DevHost01/photo.jpg => (SC Server [1ms]) => (SC on CIHost01 [20ms]) => (Your Router [5ms]) => (Your ISP [24ms]) => (Content Host [20ms]) [70ms total] TOTAL FOR PAGE: 96ms. 

 

Your request still went through the SC tunnel, but then had to get to your router, out to your ISP, then too the content host's servers.  It took 70ms, almost three times as long as the other requests, and your test couldn't continue until it was finished.

 

With Lots Of Simultaneous Tests

 

The speed of a Sauce Connect tunnel is limited by the network bandwidth between the SC server and the SC client; it's impacted by the network connection you've paid for, the conditions on the internet as a whole and any routing your provider does.

Once you have multiple requests going over a connection at once, they start having to share your available bandwidth.  Once the network connection is 'full', individual requests start taking longer, and this gets worse for every request made at the same time.

 

Restrict which traffic is sent through Sauce Connect

 

There are two things you can do to alter what traffic is sent via SC (and thus lower your test times).  By building a list of URL patterns to send, you can instruct SC to either:

• send all matching traffic through SC and all non-matching directly via the internet (tunnel-domains)
• send all matching traffic via the internet and all non-matching via SC (direct-domains)

You can't use both options; Only one is valid at a time.

 

When should I create a list of Sauce Connect transmitted domains?

• Your sites use a substantial number of 3rd party resources or a short list of internally hosted domain names
• You know for sure the top level domains or individual subdomains where your tests are hosted
• All of the domains and subdomains hosting your test are accessible within your corporate network

We call this list the tunnel-domains list.

 

When should I create a list of internet transmitted domains?

• You know for sure what 3rd party resources you use
• You are not sure where all of your internet resources are hosted
• You have a short list of external resources or a long list of internal hosted domain names

We call this list the direct-domains list

 

I'm still not sure what list to use

Use a list of Sauce Connect avoiding domains.  This may not give you all the speed increases you want but will ensure your tests do not stop working because the Sauce Labs browser is unable to reach the relevant sites.

(We recommend that, if you aren't sure what external resources and internal domain names your sites under test use, that you conduct an order and find out before reaching out with Support problems relating to network speed problems)

 

Building the List

 

Domain Discovery

 

We recommend building the list of domains by direct knowledge of your system; that is, checking the design documents, architecture and code to determine what external resources are in use.  If you are not the system developers, we recommend reaching out to that team for assistance.

If you are only aware of a limited number of external resource domains, we recommend using a direct-domains list composed of these domains.

The last, far worse option, is to use the Developer Network Tools in a browser session to check the resources being requested by your tests.  This will need to be done for each page in your application you wish to test, in order to be certain you've gathered all the required information.

Sauce Labs Support is unable to construct this list for you.

 

Writing The List For Sauce Connect

 

You pass the list of domains to SC as a comma separated list of domain names only.

For instance, if you're building a tunnel-domains list (a list of all domains to send through the tunnel) and you're testing pages hosted at:

 

devhost01/index.html
devhost01/login.html
someotherhost/do_something.html

 

You remove everything but the domain names, then combine them with a comma:

 

devhost01,someotherhost

 

Subdomains can either be listed explicitly, or matched with a wild card.  For instance, if you are listing the domains

 

www.someurl.com
login.someurl.com
adifferenturl.com

You could use

 

*.someurl.com,adifferenturl.com

Using a wildcard for a domain also matches for the domain by itself.

 

someurl.com
login.someurl.com
www.someurl.com
adifferenturl.com

Can be turned into

 

*.someurl.com,adifferenturl.com

 

Passing the list to Sauce Connect

 

Once you have your list build, you can pass it to Sauce Connect by adding it to the rest of your Sauce Connect start up commands.

 

A list of URLs to send direct through the internet

 

Use direct-domains

 

bin/sc your other parameters --direct-domains *.someurl.com,adifferenturl.com

 

A list of the only domains to send through the Sauce Connect tunnel

 

Use tunnel-domains

 

bin/sc your other parameters --tunnel-domains devhost01,devhost02 

 

Important Notes

 

It's not possible to specify both tunnel-domains and direct-domains.

All matching URLs will be caught by wildcards.  For instance, if you're using

 

--direct-domains *.someurl.com

 

And you need to send www.someurl.com through the tunnel, you will be unable to do so.  In this case, you'll need to list out each subdomain you wish to set as a direct domain.