Table of Contents for

Testable JavaScript

Testing JavaScript in a browser typically involves Selenium. Testing with Selenium usually requires a chunk of Java code running on the same box as the browsers you want to spawn to run your tests, and a client-side API for controlling the remote browser. Selenium2/WebDriver can control Firefox, Chrome, and Internet Explorer for Mac OS X and Windows.

You can write Selenium tests in a variety of languages, or you can use a Firefox plug-in that will generate your tests in various languages by following your mouse movements and keystrokes. Selenium also provides a set of assertion and verification functions that test the current page to ensure the current state is valid.

Using the Selenium IDE is the quickest way to get something to play with. While in any version of Firefox, go to the SeleniumHQ site and get the latest version of the IDE (1.10.0 as of this writing), and let Firefox install the add-on.

Now load your website and open the Selenium IDE (Tools→Selenium IDE). Set the Base URL to the URL of the page where your web application resides. Click on the record button on the upper right of the Selenium IDE and Selenium will start tracking your mouse and keyboard movements as you click and type around your application. Click the record button again to stop recording.

Select File→Export Test Case As and you can save your clicking and typing in a variety of languages for Selenium2/WebDriver, or for original Selenium (Remote Control), which you should not use if you’re new to Selenium.

You can rerun these tests from within the Selenium IDE by clicking the green play button. The log at the bottom of the Selenium IDE window will let you know what is going on.

A common problem with Selenium is that it uses element IDs by default to identify the elements you are interacting with, and using a JavaScript framework that dynamically generates IDs will cause your test to fail, as the elements with these dynamic IDs will not be found during subsequent runs. Fortunately, the Target text field in the Selenium IDE lets you remedy this situation by using XPath or CSS expressions to locate elements, instead of the IDs used by default (of course, if you are setting element IDs yourself you will not have this problem). Click the find button next to the Target text field to locate elements you want to target when changing selectors.

You can also run saved test cases from the command line using JUnit. Export your test case as a JUnit 4 (WebDriver Backend) file and name it something interesting. The IDE will put the following declaration at the top of your file:

package com.example.tests;

Change the declaration to match your environment, or just delete that line.

Now you’ll need both the current version of the Selenium server and the client drivers. From the SeleniumHQ site, download the current version of the Selenium server (version 2.28 as of this writing) and the Java Selenium client driver (version 2.28.0 as of this writing). You will need to unzip the Java Selenium client.

To compile your exported Selenium script you need the selenium-server JAR:

% java -cp path/to/selenium-server-standalone-2.28.0.jar test.java

This will compile your exported Selenium test case. To execute the test you need to start the Selenium server, like so:

% java -jar path/to/selenium-server-standalone-2.28.0.jar

And now you can run your JUnit test case (all on one line):

% java -cp path/to/selenium-server-standalone-2.28.0.jar:Downloads/
selenium-2.20.0/libs/junit-dep-4.10.jar:.
org.junit.runner.JUnitCore test

You need the path to the Selenium server JAR and the JUnit JAR (which is supplied by the Java Selenium client code if you do not already have it somewhere). The preceding code assumes you deleted the package declaration. If not, you need something like this (again, all on one line):

% java -cp selenium-server-standalone-2.28.0.jar
:selenium-2.20.0/libs/junit-dep-4.10.jar:.
org.junit.runner.JUnitCore com.example.tests.test

The compiled Java program must reside in com/example/tests for the Java interpreter to find it (or you can change the class path).

Using the Selenium IDE is clunky; you are better served by handwriting the test cases yourself (you can use JUnit for this). But note that this becomes an exercise in learning XPath or CSS selectors and/or using ID attributes judiciously throughout your HTML so that Selenium can “grab” them and manipulate your application: clicking links and buttons, dragging and dropping, editing form elements, and so on.

You can use either the assert or the verify family of Selenium functions to verify your application’s functionality. Note that the assert family of functions will fail the test immediately and skip to the next test function, while the verify family of functions will fail the assertion but continue running further code within the test function. You should almost always use the assert family of functions in your Selenium tests.

Fortunately, there are JavaScript bindings for Selenium (both Remote Control and WebDriver) by way of npm packages for NodeJS, so we can write Selenium integration tests using our beloved JavaScript.

WebDriver

Using the webdriverjs npm module to drive Selenium2 is straightforward:

var webdriverjs = require("webdriverjs")
    , browser = webdriverjs.remote({
        host: 'localhost'
        , port: 4444
        , desiredCapabilities: { browserName: 'firefox' }
    })
;

browser
    .testMode()
    .init()
    .url("http://search.yahoo.com")
    .setValue("#yschsp", "JavaScript")
    .submitForm("#sf")
    .tests.visible('#resultCount', true, 'Got result count')
    .end();

With the Selenium server started locally, the preceding code will start a Firefox browser, search for “JavaScript” at the Yahoo! search page, and ensure that an element whose id is resultCount is visible.

Generating a screenshot is equally easy. Simply add the saveScreenshot call:

var webdriverjs = require("webdriverjs")
    , browser = webdriverjs.remote({
        host: 'localhost'
        , port: 4444
        , desiredCapabilities: { browserName: 'firefox' }
    })
;

browser
    .testMode()
    .init()
    .url("http://search.yahoo.com")
    .setValue("#yschsp", "javascript")
    .submitForm("#sf")
    .tests.visible('#resultCount', true, 'Got result count')
    .saveScreenshot('results.png')
    .end();

And now you have a beautiful screenshot, as shown in Figure 6-1. Note that although the Yahoo! Axis ad appears in the middle of Figure 6-1, it is actually positioned at the bottom of the visible page. But since Selenium is taking a snapshot of the entire page, it appears in the middle. When you view this page in a browser, the ad appears at the bottom of the visible area.

Figure 6-1. Generating a screenshot with Selenium

To run this example in Chrome, you need to download the Chrome driver for your operating system and install it somewhere in your PATH. Then you simply change this line:

, desiredCapabilities: { browserName: 'firefox' }

to this:

, desiredCapabilities: { browserName: 'chrome' }

and your tests will run in Google Chrome.

How about Internet Explorer? You can download the latest IE driver for your platform from the code.google selenium site. Then put the executable in your PATH and fire it up. It starts up on port 5555 by default:

, port: 5555
, desiredCapabilities: { browserName: 'internetExplorer' }

var soda = require('soda')
    , browser = soda.createClient({
        url: 'http://search.yahoo.com'
        , host: 'localhost'
        , browser: 'safari'
    })
;

browser
    .chain
    .session()
    .open('/')
    .type('yschsp', 'JavaScript')
    .submit('sf')
    .waitForPageToLoad(5000)
    .assertElementPresent('resultCount')
    .end(function(err) {
        browser.testComplete(function() {
            if (err) {
                console.log('Test failures: ' + err);
            } else {
                console.log('success!');
            }
        })
    });

% java -jar selenium-server-standalone-2.28.0.jar -role hub

% java -jar selenium-server-standalone-2.28.0.jar
-role node -hub http://localhost:4444/grid/register

Selenium is not the only browser integration-testing framework around. Built on top of PhantomJS, CasperJS provides similar functionality as Selenium but in a completely headless environment. Using pure JavaScript or CoffeeScript, you can script interactions with your web application and test the results, including screenshots, without any Java. When using CasperJS with the latest version of PhantomJS (1.7.0 as of this writing) you no longer need X11 or Xvfb running to start up the PhantomJS WebKit browser, as PhantomJS is now built on the Lighthouse Qt 4.8.0 device-independent display framework. This means truly headless integration testing is now possible on your servers.

To use CasperJS, first you must install the latest version of PhantomJS from the code.google phantomjs site. Downloading the binary version for your operating system is easiest, but building from source is not much more difficult (unless you have an older version of Linux; I had to make some changes when compiling for Red Hat Enterprise 4/CentOS 4, due to my lack of Thread Local Storage, and to remove some SSE optimizations).

Now grab the latest version of CasperJS; 1.0.0-RC6 as of this writing.

Here is the CasperJS version of the earlier Yahoo! search test:

var casper = require('casper').create();

casper.start('http://search.yahoo.com/', function() {
    this.fill('form#sf', { "p": 'JavaScript' }, false);
    this.click('#yschbt');
});

casper.then(function() {
    this.test.assertExists('#resultCount', 'Got result count');
});

casper.run(function() {
   this.exit();
});

Here’s how to run this CasperJS script:

% bin/casperjs yahooSearch.js
PASS Got result count
%

Sweet, that was easy enough. And it is significantly quicker than connecting to a possibly remote Selenium server and having it spawn and then kill a browser. This is running in a real WebKit browser, but note that the version of WebKit that Apple uses in Safari and the version of WebKit that Google uses in Chrome are different from what is running here with PhantomJS.

How about a screenshot?

var casper = require('casper').create();

casper.start('http://search.yahoo.com/', function() {
    this.fill('form#sf', { "p": 'JavaScript' }, false);
    this.click('#yschbt');
});

casper.then(function() {

    this.capture('results.png', {
        top: 0,
        left: 0,
        width: 1024,
        height: 768
    });

    this.test.assertExists('#resultCount', 'Got result count');
});

casper.run(function() {
   this.exit();
});

The capture code can also capture a given CSS selector instead of the entire page; see Figure 6-2.

Figure 6-2. Generating a screenshot with CasperJS

This looks very similar to the Firefox screenshot captured by Selenium! The biggest difference between the two concerns specifying the exact size of the screenshot you want; CasperJS does not capture the entire browser area, whereas Selenium does.

CasperJS has other tricks up its sleeve, including automatic export of test results to a JUnit XML-formatted file. Here is the full script:

var casper = require('casper').create();

casper.start('http://search.yahoo.com/', function() {
    this.fill('form#sf', { "p": 'JavaScript' }, false);
    this.click('#yschbt');
});

casper.then(function() {
    this.capture('results.png', {
        top: 0,
        left: 0,
        width: 1024,
        height: 768
    });

    this.test.assertExists('#resultCount', 'Got result count');
});

casper.run(function() {
    this.test.renderResults(true, 0, 'test-results.xml');
});

Besides outputting test results to the console, the test-results.xml file will now contain the JUnit XML test output, a format well understood by build tools including Hudson/Jenkins. Here are the contents of that file after running this test:

<testsuite>
    <testcase classname="ss" name="Got result count">
    </testcase>
</testsuite>

Here is the console output:

PASS 1 tests executed, 1 passed, 0 failed.
Result log stored in test-results.xml

Of course, you will want to test your code in Internet Explorer, as (unfortunately) the bulk of your users are probably using it, and for that you will have to use Selenium. But CasperJS is a great addition for quick testing in a headless environment.

Several tools are capable of generating HAR files. One of the most flexible is a programmable proxy that intercepts HTTP requests and responses. The proxy can work with any browser, including mobile ones, giving it maximum flexibility.

Another option is to use a packet-sniffing tool such as tcpdump to capture HTTP traffic in PCAP format, and to then use a tool such as pcap2har to generate the HAR. This arguably gives “truer” performance numbers, as there is no proxy between your server and the client. Although this method is messier, I encourage you to check it out if the proxy method does not work for you. For instance, mobile browsers do not allow you to set proxies, so generating HARs for mobile devices requires a packet sniffer. Visit this code.google webpage for more details.

% /bin/sh bin/browsermob-proxy

% npm install browsermob-proxy

var Proxy = require('browsermob-proxy').Proxy
    , fs = require('fs')
    , proxy = new Proxy()
    ;

    proxy.doHAR('http://yahoo.com', function(err, data) {
        if (err) {
            console.error('ERROR: ' + err);
        } else {
            fs.writeFileSync('yahoo.com.har', data, 'utf8');
        }
    });

    , proxy = new Proxy( { host: 'some.other.host', port: 9999 } )

    , proxy = new Proxy( { selHost: 'some.other.host', selPort: 6666 } )

var Proxy = require('browsermob-proxy').Proxy
    , webdriverjs = require("webdriverjs")
    , fs = require('fs')
    , proxy = new Proxy()
;

/*
 * Call into the proxy with a 'name' for this session, a Selenium
 *     function to run the interaction we want to capture, and
 *     finally a callback that will contain either the HAR data or
 *     an error
 */
proxy.cbHAR('search.yahoo.com', doSeleniumStuff, function(err, data) {
        if (err) {
            console.error('Error capturing HAR: ' + err);
        } else {
            fs.writeFileSync('search.yahoo.com.har', data, 'utf8');
        }
});

/*
 * This is the Selenium function that gets passed the proxy webdriverjs
 *     should use and a callback to call when the interaction is done
 */
function doSeleniumStuff(proxy, cb) {
    var browser = webdriverjs.remote({
        host: 'localhost'
        , port: 4444
        , desiredCapabilities: {
             browserName: 'firefox'
             , seleniumProtocol: 'WebDriver'
             , proxy: { httpProxy: proxy }
        }
    });

    // Just run our regular Selenium stuff - note this can just
    //    be your regular test code or something special you want
    //    to capture with a HAR
    // Just pass the browsermob-proxy callback to 'end()'
    browser
        .testMode()
        .init()
        .url("http://search.yahoo.com")
        .setValue("#yschsp", "JavaScript")
        .submitForm("#sf")
        .tests.visible('#resultCount', true, 'Got result count')
        .saveScreenshot('results.png')
        .end(cb);
}

, proxy = new Proxy({
    downloadKbps: 56
    , uploadKbps: 56
    , latency: 200
})

var Proxy = require('browsermob-proxy').Proxy
    , spawn = require('child_process').spawn
    , fs = require('fs')
;

var proxy = new Proxy();
proxy.cbHAR('MyCoolHARFile', doCasperJSStuff, function(err, data) {
    if (err) {
        console.error('ERR: ' + err);
    } else {
        fs.writeFileSync('casper.har', data, 'utf8');
    }
});

function doCasperJSStuff(proxy, cb) {
    casperjs = spawn('bin/casperjs'
      , [ '--proxy=' + proxy, process.argv[2] ]);
    casperjs.on('exit', cb);
}

% node casperHAR.js casperScript.js

So, thus far we have generated HAR files, which are just JSON, and you know that you can get arbitrarily fancy, perhaps sticking their values in a database or storing the files to watch trends in your application profile. But at some point you are going to want to view the things.

Visualizing the data in HAR files is easy. The simplest method is to go to the canonical web-based viewer; simply drag a HAR file onto the page (go HTML5!) and drop it into any moderately modern browser, and you will see a waterfall graph of the HAR data. Make sure you uncheck the “Validate data before processing” checkbox before uploading your HAR. I have yet to come across a HAR file that validates correctly! Figure 6-3 shows a HAR file for our search.yahoo.com search example.

Figure 6-3. Waterfall graph for the search.yahoo.com example

This is pretty snazzy! From this graph, we can see that 26 requests were made; hovering over any bar will reveal a specific breakdown of the amount of time each request took, in order: DNS Lookup, Connecting, Sending, Waiting, and Receiving.

A much more involved example comes from Yahoo.com. In this example, shown in Figure 6-4, 81 requests were made to download the page, and the download time was 4.39 seconds (actually, the page was visible much sooner than that; the data that was downloaded at the end of the process comprised a big Flash ad). The perceived performance and the initial time until the page looks ready are the most important bits of information to pay attention to, not the total amount of time all the pieces take to download.

Figure 6-4. Waterfall graph for the Yahoo.com example

Other options are also available for viewing HAR files without having to upload them to a remote website. For starters, download the source code for the HAR Viewer. You can also easilyembed HAR graphs generated by the HAR Viewer into your own pages (the HAR files themselves can be grabbed remotely).

Another way to interrogate HAR files is with YSlow. Besides being a browser plug-in that gives grades on load performance, YSlow is also available as a command-line tool that can read HAR files and export YSlow output. You can run YSlow from the command line or from within a Node.js script via the following command:

% npm install yslow -g

The YSlow output can be in XML, plain text, or JSON format. To graphically view the YSlow output, a beacon can be sent to a YSlow visualizer, which you can also install locally if you do not want to send your precious YSlow data to a third party.

Let’s take a look at how this all fits together. After installing YSlow, we’ll feed it a HAR file and use the beacon to view the results at Showslow.com:

%  yslow -i all -b http://www.showslow.com/beacon/yslow/ yahoo.com.har

This will send our HAR output from Yahoo.com to be visualized. Then we cruise over to Show Slow and find our URL in the list of recent beacons to see the full graphical output.

In this case, a lot of people have YSlow’ed Yahoo.com, so there are nice history graphs, and of course all the grades are A’s! At the bottom of the page is a link back to the HAR Viewer for Yahoo.com—the circle is complete!

You can generate visualizations yourself using the -beacon feature—all the data provided by the beacon is detailed. Or you can leverage the Showslow code and run your own local Showslow server.

HAR files are very interesting, but of course they do not represent the complete performance picture. Entire books are dedicated to this topic, and with good reason!

HAR files are amusing and easy to generate, but they do not tell the entire story. Beyond network performance, browsers must also parse HTML, parse and execute JavaScript, and lay out and paint the browser window, and that all takes time. How much time? There are tools to measure what exactly the browser is doing while your web application is running. dynaTrace AJAX Edition for Firefox and Internet Explorer (Windows only) and Speed Tracer for Chrome are two such tools. Both accomplish the same basic tasks. While a page is loading, the tools are collecting timing information that can be graphed immediately, or saved and graphed and inspected later. By inspecting the graphed output, you can identify performance issues and then fix them. The process of collecting these low-level timings is very specific to each browser; hence, there can be no generic collector like a HAR proxy.

In this section we will take a quick look at Speed Tracer. Speed Tracer is an extension for Google Chrome.

Install the extension, and then click on its little green stopwatch icon to bring up the Speed Tracer UI. Clicking the red record button will start tracing browser internals, which mostly consists of fetching resources from the network, parsing HTML and JavaScript, and laying out and painting the browser window. This is all presented in the familiar waterfall graph. At the top of the UI are a Sluggishness graph and a Network graph. The Network graph is essentially identical to the HAR graphs we saw earlier. The Sluggishness graph is more interesting and visualizes how responsive (or not) the user interface is at the specified time. The taller peaks indicate that the browser’s single UI thread was blocked—a bad thing!

Speed Tracer provides hints regarding problem areas in your application (as does YSlow); for instance, Speed Tracer will flag an event lasting longer than 100 ms. Event handling blocks the main UI thread while events are being serviced, so handlers longer than 100 ms can make the UI seem sluggish.

Finally, Speed Tracer provides a save button to save the data so that you can load and examine it again at a later time—this is a great feature to leverage during an automatic build process. To wit, as part of our build we can automatically generate the Speed Tracer data for our application to ensure that no changes are impacting performance (we will investigate this further in Chapter 8). Figure 6-5 provides a peek at the Speed Tracer UI analyzing Yahoo.com.

Figure 6-5. Speed Tracer UI as it analyzes Yahoo.com

Load testing a web application in a browser usually involves sending your application as much traffic as possible and measuring its performance. Measuring performance typically means response time: you GET a page or POST a form multiple times and track how long the application takes to respond.

The canonical tool for this type of testing is Apache Bench. The command-line ab tool takes many options to GET, POST, PUT, or DELETE pages, and dumps out a CSV file of the results. In this chapter, we will work with the Node.js version, called nodeload.

nodeload has lots of great features beyond just hitting URLs repeatedly, so let’s get started. Begin by installing the tool:

% sudo npm install nodeload -g

As a basic example we will use the nl.js utility, which acts similarly to the ab Apache Bench executable:

% nl.js
1 Aug 20:28:52 - nodeload.js [options] <host>:<port>[<path>]

Available options:
  -n, --number NUMBER              Number of requests to make.
Defaults to value of --concurrency unless a time limit is specified.
  -c, --concurrency NUMBER         Concurrent number of connections.
Defaults to 1.
  -t, --time-limit NUMBER          Number of seconds to spend running
test. No timelimit by default.
  -e, --request-rate NUMBER        Target number of requests per
seconds. Infinite by default
  -m, --method STRING              HTTP method to use.
  -d, --data STRING                Data to send along with PUT or
POST request.
  -r, --request-generator STRING   Path to module that exports
getRequest function
  -i, --report-interval NUMBER     Frequency in seconds to report
statistics. Default is 10.
  -q, --quiet                      Supress display of progress
count info.
  -h, --help                       Show usage info

A typical usage of this utility looks like this:

% nl.js -c 10 -n 1000 http://yhoo.it/XUdX3p

Do not try this at home, as this will hit Yahoo.com 1,000 times, with 10 requests happening at a time. Here is what I got when I did not try this at home:

% nl.js -c 10 -n 1000 http://yahoo.com
http.createClient is deprecated. Use `http.request` instead.
Completed 910 requests
Completed 1000 requests

Server:                                 yahoo.com:80
HTTP Method:                            GET
Document Path:                          /
Concurrency Level:                      10
Number of requests:                     1000
Body bytes transferred:                 207549
Elapsed time (s):                       11.19
Requests per second:                    89.37
Mean time per request (ms):             111.23
Time per request standard deviation:    147.69

Percentages of requests served within a certain time (ms)
  Min: 86
  Avg: 111.2
  50%: 94
  95%: 113
  99%: 1516
  Max: 1638

These 1,000 requests averaged 111.2 milliseconds round trip, with one request taking 1.638 seconds to return. This kind of testing works best when also generating server-side statistics. Normally you would let this test run much longer, not only for “endurance testing” (can your application sustain a lot of hits over a long time?) but also to watch CPU, RAM, and disk utilization on the web server, as well as on any other backend machine that is providing services to your web application. Conveniently, nodeload can also generate those values.

nodeload also has a great reporting function. To see it, let’s look at a full example. First we will put a long-running load on our web application. While our web server is servicing those hits, we will measure its CPU, disk, and RAM load. Finally, while the test is running, we can watch a live-updated graph of web server performance.

The first step is to send lots of hits. Here we’re sending 100,000 of them:

% nl.js -c 10 -n 100000 -i 2 http://localhost:8080

While this is running, nodeload runs a web server on port 8000 to display the request activity (see Figure 6-6).

Upon completion, the final HTML and JSON values are saved into the current directory—pretty snazzy.

Meanwhile, you can monitor what is happening on the server side using your favorite statistics generator (vmstat, iostat, uptime, ps, etc.), using nodeload to graph and persist the values. Using Linux and the /proc filesystem, you can report and graph server-side values easily.

nodeload also provides a handy Loop class that will execute code at a specified frequency. As an example, this construct will execute the getMemory and getCPU functions once every five seconds, at most:

var myLoop = new loop.Loop(
    function(finished, args) {
        getMemory();
        getCPU();
        finished();
    }
    , []   // No args
    , []   // No conditions
    , .2   // Once every 5 seconds
);

myLoop.start();

The last parameter in the preceding code is the maximum number of times per second that the loop should execute.

Figure 6-6. nodeload graphical output

The header of this script sets up all our variables:

var reporting = require('nodeload/lib/reporting')
    , report = reporting.REPORT_MANAGER.getReport('System Usage')
    , memChart = report.getChart('Memory Usage')
    , cpuChart = report.getChart('CPU Usage')
    , loop = require('nodeload/lib/loop')
    , fs = require('fs')
;

Here I am defining a single report ('System Usage') with two charts, 'Memory Usage' and 'CPU Usage'. The getMemory function uses the Linux /proc filesystem to get memory usage data:

function getMemory() {
    var memData = getProc('meminfo', /\s*kb/i);

    memChart.put({ 'Free Memory': memData['MemFree']
      , 'Free Swap': memData['SwapFree'] });
    report.summary['Total Memory'] = memData['MemTotal'];
    report.summary['Total Swap'] = memData['SwapTotal'];
}

We can, of course, pick out any value we like. The getProc utility function is not shown; it simply takes a file in the /proc filesystem and objectifies it. The interesting bits are adding the current data point to the memory chart we defined in the header and adding it to the report summary, which is displayed in the righthand column on the reporting web page.

The getCPU function is similar:

function getCPU() {
    var meminfo   = fs.readFileSync('/proc/loadavg', 'utf8')
        , vals    = meminfo.split(/\s+/)
        , cpuInfo = getProc('cpuinfo')
    ;

    cpuChart.put( {
        '1 Min': vals[0]
        , '5 Min': vals[1]
        , '15 Min': vals[2]
    });

    report.summary['CPU'] = cpuInfo['model name'];
}

Again, we grab some values and add them to the CPU chart. Fire up the script and go to port 8000 to view the live results.

The summary information is displayed on the right, and live-updating graphs are in the main column. When the script ends, by whatever means necessary, a file will be available in the local directory with the HTML of the graph.

nodeload has a lot of other tricks up its sleeve, including multiple loops for parallel execution of loops; a statistics package for further analysis of data sets; and a very flexible, programmatic way to specify requests (you do not have to just send vanilla HTTP requests). Of course, you can wrap any testing, hitting of web pages, or anything else within a loop, and easily graph the result.

Finally, the monitoring package allows for easy monitoring and collection of runtime data to prod your code for slowness and bottlenecks.

The WebKit Developer Tools provide excellent support for tracking the memory usage of your client-side JavaScript. As you will see in this section, the Profile panel is your friend for both memory and CPU tracking.

Memory usage

First, to get a look at overall memory usage, fire up your Chrome browser and go to chrome://memory-redirect/. There is a lot of data here, a summary of which you can find by selecting Wrench→Tools→Task Manager or Windows→Task Manager. This output is similar to that of the top utility but within the browser, including CPU usage, I/O, and network status information for each plug-in and tab, as well as overall browser activity (see Figure 6-7).

You can alter the columns that are shown by right- or context-clicking on a column header. For now, JavaScript memory is most useful. Other potentially interesting values are current cache sizes (see Figure 6-8) and, of course, “Goats Teleported.”

There is a lot of good overall information here. Let’s take a closer look at our application.

The heavy memory user here is Gmail. This is not surprising, as Gmail is a single-page web application with lots of JavaScript (like Google Calendar).

Figure 6-7. Chrome Task Manager

Figure 6-8. JavaScript memory per tab/process

Note

As all recent browser versions use mark-and-sweep for garbage collection instead of reference counting, cycles can now be freed properly. But there are still plenty of other ways for your application to consume memory! A good overview is available on the Mozilla Developer Network site.

To determine whether an application is leaking memory, our first stop is the Memory graph in the Timeline panel (see Figure 6-9).

Figure 6-9. Memory graph in the Timeline panel

Memory usage can go up as long as it comes back down. As Figure 6-9 shows, this is a well-behaved application in terms of memory usage—usage goes up and down as the application requests and then releases memory. If your memory usage always increases and never decreases, you may have a memory leak.

In our case, the Profiles tab in the WebKit Developer Tools comes to our rescue! (See Figure 6-10.)

Figure 6-10. The Profiles tab in the WebKit Developer Tools

A heap snapshot makes it very easy to see how much memory a set of JavaScript objects is using. When you take a heap snapshot, the application runs the garbage collector first so that you are getting a “clean” view of actual memory usage (see Figure 6-11). Use the Class Filter text box to filter the resultant objects into the ones you are concerned about.

Figure 6-11. Heap memory used by RegExp objects

According to Figure 6-11, there are more than 1,200 regular expression objects; drilling down, you can inspect every one of them. Besides your own objects, you can also filter on DOM objects. If you are concerned that a certain action is leaking memory, take multiple snapshots. In the Summary view, shown in Figure 6-12, you can see which objects were allocated between each snapshot (note the pull-down at the bottom where I have selected “Objects allocated between Snapshots 1 and 2”).

Figure 6-12. The Summary view

Finally, you can compare two heap snapshots for another view of what has changed between the two (see Figure 6-13).

Figure 6-13. Comparison between two heap snapshots

Here, I used a lot of memory between Snapshot 1 and Snapshot 2. According to the Comparison view, more than 1,000 new array objects were created between the two snapshots. To determine whether this was intended, you can drill down into each object to see what they contain.

Interestingly, there currently is no way to trigger a heap snapshot programmatically. One solution to this issue is to insert a debugger statement into your code, and manually trigger a heap snapshot once the interpreter stops.

You can read about Gmail’s approach to finding and squashing memory leaks in its code. Also, the Chrome Developer Tools team has created a leak finder.

CPU usage

Collecting a JavaScript CPU profile from the Profiles tab shows similar information from the CPU usage angle. You can easily inspect how much time (real or a percentage) your program spends in each function, and how many times each function was executed. Click Start to begin capturing CPU information; you can click around or perform some actions and then click Stop to see what happened.

Figure 6-14 shows that the YUI function to add a node was the heavy hitter (although it was called many times, it still only took 40 ms to decorate the page). This displays the call stack to that function, and clicking on the link on the right will take you to the actual code.

Figure 6-14. JavaScript CPU usage

Clicking the % button will toggle the display between real time and percentage time spent in each function.

By taking heap snapshots and collecting CPU profiles, you can gain a very intimate understanding of what exactly your application is up to while it is running.

If you are interested in tracking noninteractive code paths, use console.profile:

<html>
    <script>
        var Cache = function() {
            this.cache = {};
            this.add = function(key, val) {
                var now = new Date().getTime();
                cache[key] = { val: val, time: now };
            };
        }

        var cache = new Cache();
        console.profile('squared');
        for (var i = 0, l = 1000000; i < l; ++i) {
            cache.add(i, i ^ 2);
        }
        console.profileEnd('squared');
    </script>
</html>

Loading this code in a WebKit-based browser and opening the Profiles tab will produce output similar to that shown in Figure 6-15.

Figure 6-15. CPU usage from console.profile

The Profiles tab has captured the “squared” profile report, and now it is available for inspection.

Node.js exposes the V8 profiler, which you can use to gather CPU and memory usage data beyond console.trace. Using the webkit-devtools-agent npm package makes profiling Node.js server-side applications almost as easy (and pretty) as profiling client-side ones. So, install it, and get ready to rumble!:

% sudo npm install webkit-devtools-agent -g

This package allows your Node.js application to utilize the Heap Snapshot and JavaScript CPU Profiles tabs in a WebKit-based browser (such as Chrome or Safari). To use the package, simply require it at the top of your program and then signal your Node.js process with a USR2 signal:

var agent = require('webkit-devtools-agent');
process.kill(process.pid, 'SIGUSR2');

Of course, you can also send the USR2 signal externally from your program. This starts up a local daemon listening for connections from a WebKit browser that will then fire up the Developer Tools to analyze your program.

To get all this to work, you will need to start a copy of Chrome with the -remote-debugging-port=9222 option. On a Mac, from a shell issue the following command (all on one line):

% /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
--remote-debugging-port=9222 -user-data-dir=/tmp

Another WebKit-based browser can use this copy of Chrome to connect to debug the Node.js application. Once your application has started and you have signaled it with USR2, you can now connect to the following URL from another WebKit browser: http://localhost:9222/devtools/devtools.html?host=localhost:1337&page=0.

This loads the Developer Tools as served by the first WebKit browser, which speaks the Web Sockets protocol to the webkit-developer-agent spawned by your Node.js program. While the entire set of Chrome Developer Tools appears, only the Profiles tab actually works (see Figure 6-16).

Figure 6-16. Profiles tab from webkit-developer-agent

% sudo npm install heapdump -g

require('heapdump');

% kill -USR2 <NodeJS process ID>

process.kill(process.pid, 'SIGUSR2');

% node --prof myapp.js

% sudo npm install profiler -g

% /bin/sh tools/build-nprof

% .../node_modules/profiler/nprof path/to/v8.log