Auto-tools/Projects/SpeedTests

Results

See results at http://brasstacks.mozilla.com/speedtests/results.html.

Description

SpeedTests is an automated suite of browser tests in which all tests are executed on a series of browsers. Tests can be freeform but are expected to a) report results and b) have a definite termination point, for which purpose a small set of JavaScript functions are provided. Likely candidates are the IE 9 Test Drive performance tests, suitably modified.

Architecture

Conceptually the system can be split into four parts: the tests, the browser controller, the report server, and test server (the latter two may be combined). However they are best understood by looking at the whole process rather than the individual parts.

Upon starting, the browser controller first fetches a list of tests from the server (in case any have been added or removed since last run--this means clients do not have to be updated when tests change). It has a list of browsers likely to be installed on the target platform, and iterates through the existing browsers, running each one with each test, separately. The controller loads a fresh profile before executing each test, and shuts down the browser after each test finishes, to eliminate interactions between tests. It also has a simple HTTP server running on a special port, which awaits a callback from the browser containing the results after each test executes.

The tests use a common set of JavaScript functions to collect and report results. The browser controller collects results from each browser and forwards them onto the results server (the latter can be disabled for local testing). When the last browser has executed the last test, the controller shuts down its HTTP server, prints a report to stdout, and exits.

The test server can be the same server as the results server, or it can be separate. In the current setup, they are separated, with the test server running internally, since we can't distribute the modified tests. It is the test server that also serves up the JS library for reporting results.

The location of the test and result servers is configured in an ini file on the client.

Implementation

The browser controller is a single Python file, requiring an installation of Python 2.6 or higher. We may build a standalone Windows executable with py2exe for convenience.

The server is a Python application using the web.py framework along with a MySQL database to store results.

Tests are HTML, JavaScript, and associated files. The server also provides a file containing several JavaScript functions to be used to collect and report results.

Source code is in hg: http://hg.mozilla.org/automation/speedtests/

Unfortunately, I think legal restrictions prevent us from distributing the Microsoft-originated tests themselves.

Configuration

The main configuration task is unfortunately not easy. All the browsers must have a stored profile that permits its browser to

• open a new window (all tests are run in a separate window to control window size)
• AJAX calls, to send the results to the server
• load a page from localhost

Some browsers are more particular than others about what is allowed out of the box.

The profiles should also have empty caches or a clear-cache-on-exit setting. This ensures that any changes to the tests on the server will be picked up the next time the clients are run.

I have been collecting some stock profiles, but unfortunately they are not always compatible between releases. The most reliable way to set up the stored profiles is through the "archive" and "load" commands, followed by testing in testmode (see below).

Finally, in order to prevent updates to browsers that might affect performance while tests are being run, it is recommended that the network be partially disabled, with access only to the test server. This can be done by disabling DNS and putting the server IP into the hosts file. A standalone script, nw.py, has been provided to enable and disable the DNS on Windows machines (must be run as administrator).

Usage

The client can be started by just running "python speedtests.py". If you don't want to run all the browsers, you can append a list of desired browsers, e.g. "python speedtests.py nightly 'internet explorer' chrome".

It can also be run in test mode by appending the "-t" or "--testmode" option. This causes the server to return simple test pages that do not run any tests but exercise the framework itself, namely, chaining the tests and pinging back the local controller.

There are also two commands to help you set up and test the stored profiles:

• archive <browser>: Store the current profile for <browser>
• load <browser>: Starts <browser> with the currently stored profile

Client Maintenance

We limit network access on the machine in order to prevent browser and system updates, which might throw off results if a test is running at the same time. Unfortunately this requires periodic manual maintenance in order to install desired updates (e.g. to test against recent browser releases), but it should be minimal.

Network access is limited by setting the DNS server to localhost, i.e. an invalid host. Thus all DNS lookups, except those in the hosts file, will fail, preventing the majority of Internet access. There's a helper program distributed with the client called nw.py that can be used to disable and re-enable DNS.

This is the process for updating a SpeedTest client:

1. Open a terminal as administrator.
2. Go to the speedtests client directory (generally /Users/mozilla/speedtests/client).
3. Run python nw.py enable to enable full network access.
4. Run Firefox, Chrome, and Opera, checking each for updates.
5. Run the Apple Updater to look for Safari updates (don't install other software like Quicktime!).
6. Run Windows Update.
7. Run Windows Update again to see if there are subsequent updates.
8. Run python nw.py disable to disable full network access.
9. Reboot.

Note that it is unnecessary to update Nightly, since the client automatically downloads the latest version.

Major Tasks Remaining

• Set up a Mac box. (8-16 h)

• Set up a Linux box. (8-16 h)

• (to do eventually) The local controller could act as a proxy for the test server. This would allow better logging on the client side in order to diagnose problems and to provide the tester with immediate results.