Web-Layer Tests
Last updated
Last updated
Web layer tests touch on various Web technologies starting from the most basic measurement of availability of web server all the way up to performing precision transactions on a target. Web layer tests measure metrics like server availability, response time, throughput, redirects, response code, and page load performance.
For more information about HTTP server tests, see HTTP Server Tests.
Page load tests use te-chromium, a browser based upon the Chromium browser codebase, to obtain in-browser site performance metrics. The metrics include the completed page load time and phase information for each DOM component. A complete explanation of how ThousandEyes presents DOM information is available here: Navigating Waterfall Charts for Page Load and Transaction Tests. Instant page load tests provide a screenshot upon test completion, while scheduled page load tests provide screenshots when errors are recorded. A list of permitted content types is available in Permitted Content Types.
Provide metrics regarding the in-browser use experience.
Identify objects preventing or prolonging page load completion.
Monitor performance across content providers.
Below is a page load test targeting Google:
HTTP server test
Agent-to-server test
BGP test
Transaction tests emulate user interactions with a website. This test performs a series of scripted steps - such as entering data into a form or clicking a button - and provides completion time and performance metrics obtained while performing scripted actions. Transaction tests use the Selenium WebDriver engine. Tests scripts are created using JavaScript, from the ThousandEyes Recorder IDE or within the test settings. You can set screenshots and markers at different points within the script to identify important points within the transaction workflow.
Emulate common user interactions, such as completing a purchase.
Alert on degradation of site performance.
Below is a test that performs a login and a search:
HTTP server test
Agent-to-server test
BGP test
For additional guidance on creating a Transaction test, see
A File Transfer Protocol server is an essential storage component of modern enterprises. This test supports FTP, FTPS, and SFTP protocols.
Verify availability and performance of FTP server.
Read, write, and list files within a user's directory.
Verify SSH operation by selecting SFTP and performing a list test to any SSH enabled server.
Here is an FTP test to speedtest.tele2.net:21.
Agent-to-server test
BGP test
URL: Specify
Protocol (FTP, SFTP or FTPS)
Domain name and port number of the server, separated by a colon. If the port number is omitted, the defaults are:
FTP: 21
FTPS: 990
SFTP: 22
Path to the file ("Download" and "Upload" Request Types) or directory on the server ("List" Request Type). Depending on the protocol, you will need either an absolute path (starting point is the root directory, "/") or a relative path (starting point is relative to the user's home directory or other directory per the server configuration). FTP and FTPS use relative paths. SFTP uses an absolute path or a relative path.
Username/Password: Enter the username and password for the FTP account. The username and password are both required. To perform anonymous FTP, enter “anonymous” as the username and your email as the password.
Request Type: Select “Download” to retrieve a file from the FTP server. Select “Upload” to send a file to the FTP server. Select “List” to retrieve a listing of the files in the directory specified by your URL setting. Downloads and uploads use "Image" (binary) transfer; listings use "ASCII" transfer.
Note: The Upload setting will use a random sequence of bytes as the contents of the file upload. The remote filename will be taken from the URL field. It is not possible to specify the file contents, but the size of the file can be specified by the Upload File Size selector. The maximum recommended file size is 2,147,483 Kb.
Limit Download Size/Upload File Size: The number of kilobytes (kB) at which to stop the transfer. Useful for transfers of large files, particularly with slow transfer rates which could result in reaching the test’s Timeout setting prior to completion.
NOTE: Do not use the Limit Download Size or Upload File Size settings in combination with the Desired Reply Code setting.
Verify Content: (List Request Type only) Check the Enable box and enter a regular expression in the field below to verify that a filename or other string(s) is present in your directory listing.
Request Mode: Select “Passive” or “Active” mode FTP. The request mode governs the whether the client or server initiates the data channel’s TCP connection. Passive mode is the more common mode, and is the mode used by web browsers when retrieving files via FTP. Active mode requires an inbound TCP connection to port 20 on the Agent performing the test. If your Agent is an Enterprise Agent, then ensure that the firewall or packet filter rules allow this connection if you have selected Active FTP request mode.
Desired Reply Code: Enter the reply code that will represent successful test completion. An FTP command can generate multiple reply codes; the Desired Reply Code setting checks the last reply code in the response. For a list of FTP reply codes, consult RFC 959.
NOTE: Do not use the Desired Reply Code setting in combination with the Limit Download Size or Upload File Size settings.
Test type: HTTP server, Page Load, or Transaction)
Test Name: This optional parameter gives the test a label. Where no label is provided, the value in the URL field will be used as the test name, along with a protocol ("http://" by default) prepended.
URL: A URL, domain name or IP address, including TCP port. If a domain name or IP address is used (i.e. protocol specification is not provided) then "http://" is assumed.
Interval: How frequently this test will be run.
Agents: This drop-down lists the ThousandEyes Cloud Agents and (optionally) Enterprise Agents that are available to your account. Select one or more agents to assign them to this test.
Alerts: When the Enable box is checked, the alert rules selected in drop-down list will be active for the test. You can select alert rules with the drop-down list, and create, modify and delete alert rules with the Edit Alert Rules link.
Transaction Script: Transaction tests execute custom Selenium WebDriver-based scripts written in JavaScript language to simulate user interaction with web page elements. Pictured below are several buttons used to insert regularly used code into transaction tests.
Each is detailed below, ordered from left to right:
Sleep Adds a sleep function set to wait 5 seconds.
Marker Adds a marker function to track script progress. Note that this can be changed from markers.set to markers.start and makers.stop to track a particular section.
Screenshot Captures a screenshot.
Credential Opens credential management options.
Advanced Settings: Provides configuration of an associated Network test for the target server(s), per the Network Test Advanced Settings tab, and provides the following settings for either the selected test type or an associated HTTP Server view, as indicated below:
HTTP Server Timing
Timeout: Seconds until the test type terminates due to an unresponsive target server. For HTTP server test, the default timeout is 5 seconds. The maximum timeout value is 60 seconds.
Target Time for View: Sets the color legend on the global map, and the corresponding font colors for the Agent results table. For example, Response Time for an HTTP server test sets the range of the legend from 0 seconds (green end) to 2x the Target Time for View (red end). Colors for results up to .5x the Target Time for View will be green; between .5x and 1x will be yellow.
Page Load Timing/Transaction Timing
Timeout: Seconds until the test type terminates due to inability to load the page in a page load test or to complete the script in a transaction test within the timeout time. Defaults and maximum values vary by type of Web test:
For page load tests, the default timeout is 10 seconds. The maximum timeout value is either 0.25 * interval (in seconds) or 60 seconds, whichever is lower.
For transaction tests, the default timeout is 30 seconds. The maximum timeout value is either 0.5 * interval (in seconds) or 180 seconds, whichever is lower.
Note that the HTTP server timeout cannot exceed the page load timeout. For example, if the test interval for the page load test is set to 2 minutes and the rule is to limit the HTTP server timeout to 0.25 * the interval, the HTTP server timeout will be 30 seconds. Since the maximum timeout for this particular page load test is 30 seconds, the HTTP timeout is set to a maximum of 29 seconds in this case.
Target Time for View: Sets the color legend on the global map, and the corresponding font colors for the Agent results table. For example, Response Time for a page load test sets the range of the legend from 0 seconds (green end) to 2x the Target Time for View (red end). Colors for results up to .5x the Target Time for View will be green; between .5x and 1x will be yellow.
Proxy Settings
Direct: Do not use proxy.
Enterprise Agent's proxy configuration: Use the agent's proxy configuration.
HTTP Authentication
Username: The username for the account being accessed by the HTTP request(s).
Password: The password for the account being accessed by the HTTP request(s).
Scheme: The following are available
HTTP Basic Authentication
NTLMv2 (a.k.a. Windows Integrated) Authentication. NTLMv2 authentication is supported for HTTP server tests only.
Kerberos: Selecting the Kerberos button from the Advanced Settings tab > HTTP Authentication options will have the test use the Kerberos configuration on each agent. The agents selected in the test will also need to be setup for Kerberos authentication in the Cloud & Enterprise Agents > Agent Settings > Enterprise Agents > Kerberos Settings subtab. See Kerberos Settings for more information.
OAuth (HTTP server only), two Initial Authentication Schemes supported with OAuth as under:
Basic Authentication
NTLM
HTTP Request
HTTP Version: Select the HTTP version for requests:
Prefer HTTP/2: Attempt HTTP/2 and fallback to HTTP/1.1 if HTTP/2 is not available.
HTTP/1.1 Only: Send request(s) using HTTP/1.1 only, no attempt is made to utilize HTTP/2.
Window Size (page load and transaction tests only): Select size and orientation (phone or tablet) from the various Desktop, Phone and Tablet options available, or configure a custom size. Defaults to Desktop Small (1024x768).
Request Method: (HTTP server only) Select the HTTP request method--either GET or POST. If POST is selected, you may specify data in the POST Body field. The default is GET.
SSL Version: Select the version of the SSL/TLS protocol to offer in the SSL Client Hello. This will set the maximum version of SSL/TLS that the connection can use, but a lower version may be negotiated by the server. The options are the following:
SSLv3: Use SSL version 3.0. No lower version can be negotiated.
TLSv1.0: The Agent will start the TLS negotiation at version 1.0.
TLSv1.1: The Agent will start the TLS negotiation at version 1.1.
TLSv1.2: The Agent will start the TLS negotiation at version 1.2.
Auto: The Agent will start the TLS negotiation at the highest version of TLS supported by its operating system. Currently the highest version is TLS 1.2 Contact support@thousandeyes.com if you require confirmation of the current version.
Verify SSL certificate: (HTTP server only) By default, certificate-related errors will result in a test error. Uncheck this box to ignore certificate errors during SSL/TLS negotiation.
Agent ID Strategy: (page load and transaction only) HTTP requests originating from a transaction or page load test must be identifiable as being a ThousandEyes Agent request. The default identification strategy is to include a custom header (X-ThousandEyes-Agent: yes) on each request. However, in certain situations, the inclusion of this this header can cause a CORS policy violation for some cross-origin requests. To circumvent this issue, HTTP requests can alternatively be made identifiable by instead extending the User Agent request header with the (ThousandEyes Agent) identifier string. Selecting the Extend User Agent Header option will automatically include this identifier string and it will be appended into User Agent text input. If the (ThousandEyes Agent) identifier string is removed from the User Agent text input while the Extend User Agent Header option is selected, the test configuration will not be valid and cannot be saved.
Custom Headers: Enter one or more HTTP header strings in the form <stringname>: <value>. Note the whitespace between the literal colon character and the placeholder <value>. The custom header(s) will be transmitted with the target page request (page load test) or each page request (transaction test) but not for objects within a page. When adding multiple headers, delineate between individual headers using a line break.
Override DNS: (HTTP server only) Instead of using standard DNS resolution, allows you to specify the IP address to which the target's domain name will resolve. Note that the specified IP address is not that of a DNS server, but the IP address that will be used as the target for the test. This setting is useful for targeting a specific server within a cluster, or when testing HTTPS URLs that require a Server Name Indication (SNI) in the TLS negotiation that is different from the domain name-to-IP address mapping required to access the URL.
Client Certificate: (HTTP server only) Configure a client-side certificate, which will be sent in the SSL handshake to the web server to authenticate the client. Check the Enable box, then copy your client certificate (both the private key and the public certificate) in PEM format and paste into the Client Certificate field.
If your certificate is in PKCS#12 format (.pfx file extension), you may use the openssl utility to create a PEM version. For example, the openssl command for a client certificate mycert.pfx with a password would be:
Then edit the output file clientcert.pem using a text editor to remove any text before, after, or in between the certificate and private key. The file should look like the following:
NOTE: The private key must be placed first, then the certificate.
Unsafe Legacy Renegotiation: (HTTP server only) Allows TLS renegotiation with servers that do not support Secure Renegotiation described in RFC 5746. This option is enabled by default for all tests with HTTP options, but can be disabled by unchecking the box.
HTTP Headers
Show HTTP headers in waterfalls: (page load and transaction) Make available HTTP request and response header information for each object in the waterfall displays.
HTTP Response
Desired Status Code: (HTTP server and page load) Sets the HTTP status code returned by the server that is defined as a successful test (i.e. no errors will be displayed in the test table results, no response code-based alerts generated, etc...). By default, either a 200-level or 300-level status code is considered a successful return code. Uncheck the box and enter a response code in the field below to use a different response code.
Verify Content: (HTTP server only) Search the HTTP response headers and body (similarly to a curl -i command) for text matching a given POSIX regular expression. Headers and body are searched separately. If no match occurs, the test shows an error condition. Note: the HTTP server test does not execute any JavaScript code, therefore the content generated by JavaScript cannot be verified by this feature. JavaScript-generated content can be matched using a transaction test.
Limit Download Size: (HTTP server only) Load only the first number of kiloBytes (kB) specified in the field below the Enable box. The result is not guaranteed to be exactly the number specified, but can be slightly more--but always within a few percent, or less as the size of the download is increased. Note that this function does not use an HTTP Range header, so the HTTP response code should not be affected (i.e. success is a 200 OK response, not a 206 Partial Content response).
HTTP server tests provide a world map containing availability, and on location-by-location basis, the response code served by the target web page, and number of redirects from URL requested until the final page was served.
Page load tests provide all the content from an HTTP server test, along with a page load table, showing the breakdown of the data received by domain and provider, as well as a waterfall chart, which shows the load time, source and provider for each component of the page. The page load test also provides access to DOM load and page load times, which provide elapsed times from the request start.
Transaction tests provide page load detail for each page visited in a transaction, timing information for custom defined markers, screenshots (if configured) as well as overall transaction time and completion percentage, on an agent-by-agent basis.
FTP server tests provide availability, response time and throughput metrics, as well as FTP reply codes for an FTP session.
Specific proxy configuration: Choose from one of the in-app proxy configurations to use.
