We recently had a customer from a large clothing retailer ask us if there was any way to ensure that data, such as a username/password combination, could be restricted such that it was “checked out” and available only for a specific concurrent user. This is very common with logins, where systems often will prevent concurrent logins from multiple IP addresses.

While BrowserMob does not have a concept in which data rows can be “checked out”, some simple scripting can achieve the same results. The key is in creative use of the browserMob.getUserNum() and browserMob.getTxCount() APIs. You can learn more about them by reading up on the BrowserMob APIs.

The getUserNum function returns 0, 1, 2, etc based on the concurrent user in your load test. So if you have a 100 user test, getUserNum will return between 0 and 99. It’s important to understand that it will return the same value for the same user throughout the test.

The getTxCount function returns 1, 2, 3, etc based on the number of cycles for that specific user. This number will effectively be a counter of the unique number of transactions that that particular user has executed. So user 1 and user 100 will both have a getTxCount of 1 returned, but by the time user 100 sees it, user 1 might already be on transaction 50.

Now suppose you want to run a 1000 user test in which you never concurrently log in with the same user. All you need to do is pre-create 1000 user accounts and then write your script like so:

var userId = browserMob.getUserNum();
var username = "test-" + userId;
var password = "password";
selenium.type("username", username);
selenium.type("password", password);

This works great, but what if you want to use more than 1000 logins? Suppose you want to use up to 10,000 logins among the 1000 user test? This is where the getTxCount function comes in to:

var loginsPerUser = 10;
var userNum = browserMob.getUserNum();
var txCount = browserMob.getTxCount();
var userId = userNum * loginsPerUser + txCount % loginsPerUser;
var username = "test-" + userId;
var password = "password";
selenium.type("username", username);
selenium.type("password", password);

What this does is allocate 10 logins per concurrent user. So user 1 will get usernames test-0, test-1, …, test-9 while user 8 will get usernames test-80, test-81, …, test-89, etc. Because of the mod call (%) the ten usernames will simply wrap around once they’ve been used.

Tweet This Post 

API · Scripting

To demonstrate how you can use our new API to leverage deeper integration with your internal monitoring tools, we’re going to guide you through an example that connects Nagios (a ubiquitous open source monitoring tool) with BrowserMob’s web site monitoring service.

Getting it all setup:

Since this is intended to be a quick how-to, we’re going to assume that you already have a working Nagios installation behind your firewall and an active monitoring job with BrowserMob. Here at the BMob we eat our own dog food, utilizing our own monitoring service to monitor BrowserMob.com. For this example, we’ll use a monitoring job called “BMOB” for our Nagios integration.

What you will need:

1. API Key & API Secret. Log on to browsermob.com with your account and under Home > My Profile you will find your API key and secret.
2. CLI BrowserMob API tool. Download our nifty API command line tool from http://github.com/rferreira/bmob-python
3. Nagios 3.06. We have it installed on Ubuntu Jaunty for this example.
4. jsonpretty. This just makes JSON strings human-readable in the CLI. Get it here: http://github.com/nicksieger/jsonpretty

Getting to know your monitoring job:

Before we can actually wire anything into Nagios we need to find out the internal id of a monitoring job. In the BrowserMob web interface monitoring jobs have friendly names like “BMOB”, but internally they are referenced by a unique id such as “fe33b13dc0764588b5eabf747a96a48b”.

You will need the monitoring job’s unique id. You can get it by running the following query (replacing the credentials with your own):

$ ./bmob.py -c XXX:XXX http://browsermob.com/a/m/all | jsonpretty
[
{
"browsers": [
"FF3"
],
"name": "BMOB",
"lastBilled": null,
"alertEmail": "support@browsermob.com",
"preferenceId": "7ea6d3b47c8c4a1c8d30db7fef9d5fd1",
"lastRun": 1273007522255,
"deleted": false,
"enabled": true,
"id": "fe33b13dc0764588b5eabf747a96a48b",
"lastUpdated": 1273005121243,
"frequency": 15,
"locations": [
"DALLAS",
"SING",
"AMS",
"NY",
"DC",
"DUBLIN",
"SF"
],
"scriptId": "21312a2da1834f2aa02db73f32037619",
"accountId": 2,
"email": "raf@browsermob.com"
}
]

Look for the “id” property in the JSON response.

Wiring it all up:

Now we need to write a wrapper script to query and parse the API results. Create a file called “check_bmob.sh” with the following contents:

#!/usr/bin/env bash
 
# RETURN CODES:
OK=0
WARNING=1
CRITICAL=2
UNKNOWN=3
 
WARNING_T=2000
CRITICAL_T=5000
 
ID="fe33b13dc0764588b5eabf747a96a48b"
 
# dates
START=$(date -u  --date="5 mins ago" +%s)000
END=$(date -u  +%s)000
RESP=$(/opt/bmob-python/bmob.py -d metric=responseTime,start=$START,end=$END,resolution=hour –c XXX:XXX http://browsermob.com/a/m/$ID | tr "," "\n" | grep responseTime | awk -F ":" '{print $2}')
 
for t in $RESP
do
   if [ $t -gt $CRITICAL_T ]
      then
         echo $t
         exit $CRITICAL
   elif [ $t -gt $WARNING_T ]
      then
         echo $t
         exit $WARNING
   fi
done
 
exit 0

What this script will do is look up the response time for the last 5 minutes and trigger an alert if the response time is greater than the threshold for WARNING_T or CRITICAL_T.

Now, we just need to tell Nagios to use it; the sample config below should do the trick:

# defining the command
define command {
    command_name    check_bmob
    command_line    /usr/lib/nagios/plugins/check_bmob.sh
}
 
define hostgroup {
    hostgroup_name website
    alias web site
}
 
define host {
    host_name browsermob.com
    check_command check_http
    alias login-check
    use generic-host
}
 
define service {
    hostgroup_name                  website
    service_description             response_time
    check_command                   check_bmob
    host_name                       browsermob.com
    use generic-service
}

Please keep in mind that Nagios’ configuration files can be–and usually are–fairly complex. The example above is purposely simple and may need to be modified to work in your environment.

If everything works as planned you should be able to log in to the Nagios web interface and see:

Pudding

Official BrowserMob API documentation:

http://cdn.browsermob.com/api.html

Tweet This Post 

API · Example · Monitoring · Nagios · tools

The BrowserMob team is excited to launch our new API, giving customers access to all their data (including load test results and monitoring reports) through a simple programmatic interface. The API is still in beta and will likely change over the next few weeks, but we welcome everyone to take a look, kick the tires, and send us any feedback.

Currently the API is “read only”, allowing access to load test and monitoring data. We will be adding new services in the coming weeks, including endpoints for creating load tests, monitoring jobs, and working toward complete programmatic access to anything you can do on the BrowserMob website today.

To get started, check out the API documentation. We will be updating the docs as things progress and more endpoints are added. Included in the documentation are links to some simple tools to help you get started quickly, and as always you can email the BrowserMob team if you have any questions.

- The BrowserMob Team

Tweet This Post 

API · New Feature

For load tests, yes (we’re working to add support for this to monitoring). You can use BrowserMob API to add any name/value pair to your transactions or steps. Here’s a simple example:

var selenium = browserMob.openBrowser();
 
var tx = browserMob.beginTransaction();
 
var step = browserMob.beginStep("Home Page");
 
selenium.open("http://example.com");
 
// record how long it took for some text to appear
var start = new Date().getTime();
selenium.waitForTextPresent("dynamic text");
var end = new Date().getTime();
 
// get a special cookie out and store it
var cookie = selenium.getCookieByName("myCookie");
tx.put("cookie_value", cookie);
 
// and store the "text" timing, associated with the step
step.put("text_timing", end - start);
 
browserMob.endStep();
 
browserMob.endTransaction();

The important things to notice here are that both beginTransaction() and beginStep() actually return objects that represent the transaction or step, respectively. You can then call put() on those objects to associate arbitrary data, such as custom timings or cookie values, with them.

Then when the transaction is stored in the load test database, you’ll be able to look them up in the name_value_pairs table. For more information on the test database schema, consult the documentation.

Tweet This Post 

API

We’re always working hard to improve our BrowserMob monitoring and load testing services. Over the last few weeks, we’ve pushed pushed out a bunch of improvements:

New Monitoring and Load Testing Location

Hot off the heels of Amazon’s announcement of a new US West Coast cloud data center, we are happy to report that you can now schedule load tests and monitoring jobs from this new location. Simply select the “San Jose, CA” location when scheduling tests.

Selenium 2.0 Support

In December, Selenium 2.0 alpha 1 was released. This release dramatically improves the realism and reliability of Selenium scripts. We’re proud to say that you can try out Selenium 2.0 support (but keep in mind it’s still in alpha) by simply changing your selenium script from this:

var selenium = browserMob.openBrowser();

To this:

var selenium = browserMob.openBrowser(true);

We will continue to keep BrowserMob up-to-date with all the latest happenings in the Selenium world, as well as donate our time and code back to the Selenium project. We also upgraded all the BrowserMob browsers to have the latest version of Firefox (3.5.7) and Flash.

Schedule Load Test UI Improvements

We’ve also made scheduling a load test a lot easier. We now give you a realtime estimate of what the test will cost you, changing dynamically based on your test configuration. We also display tooltips explaining things like “location”, “ramp”, and “constant”. Finally, we’re really excited to have rolled out a “Run ASAP” option that will kick off the test as quickly as it can, usually within 10 minutes.

New Script Editor

Our users love that they can write their scripts using JavaScript, so we decided to make working on that JavaScript code even easier. By utilizing the Bespin open source project from Mozilla, you now will see a rich text editor with code syntax highlighting. If for some reason you’re having trouble with it, you can always switch back to the plain text editor.

New Load Test Charts

We’ve always been proud of our realtime load test charts, but some users had recently complained that they were too heavy-weight and were slowing down their browser. Of course, this is a perfect example of why performance in the browser is starting to matter just as much as performance on the server.

Responding to this complaint, we rewrote the charts from scratch, moving from YUI Charts (Flash-based) to Flot (Canvas-based). We hope you like them!

New Scripting API Improvements

If you do advanced scripting, especially with virtual users, you’ll definitely want to take a look out the BrowserMob scripting API. We added a whole bunch of useful functions, including:

• setFollowRedirect(true) now logs all intermediate HTTP requests
• You can now automatically verify response codes
• If a 3xx response code is returned when you expected something else, the Location header is logged
• You can tie in “interceptors” for both HTTP requests and HTTP responses, allowing very advanced scripting techniques

Tweet This Post 

API · Bespin · Flot · Release Notes · Selenium · Selenium 2 · YUI Charts

Often when it’s time to run a load test or turn on website monitoring, you don’t necessarily want the transaction hitting all your third party components on the page.

For example, you don’t want your analytics software to record the visits as real visitors, since that would skew your marketing metrics. Likewise, you don’t necessarily want advertisements served up, especially if the ad vendor uses “click-through rates” (CTR) to optimize ad prices and a load test would artificially drive down the CTR.

While there are vendor-specific actions you can take to deal with this problem (ie: we cover Google Analytics here), sometimes the easiest solution is to modify your script so that the request is never made in the first place.

You can do this for both Real Browser User (RBU) and Virtual User (VU) scripts using some new APIs that we recently rolled out. They allow you to whitelist or blacklist certain hosts from having actual HTTP requests sent to them.

For example, suppose you want to exclude all requests to www.google-analytics.com from your website monitoring or website load test. Your script would need to do something like this:

var selenium = browserMob.openBrowser();
var c = browserMob.getActiveHttpClient();
 
c.blacklistRequests("http://www\\.google-analytics\\.com/.*", 
                    200);
 
browserMob.beginTransaction();
browserMob.beginStep("Step 1");
 
// rest of test...

This would ensure that any HTTP request to Google Analytics would be bypassed immediately and a fake 200 response code would be returned instead.

Sometimes it’s easier to whitelist “good” hosts instead of blacklisting specific ones. This is often the case for advertising networks, which tend to host content from dozens of different domains.

var selenium = browserMob.openBrowser();
var c = browserMob.getActiveHttpClient();
 
c.whitelistRequests(["http://www\\.example\\.com/.*", 
                     "http://images\\.example.com\\.com/.*"], 
                    200);
 
browserMob.beginTransaction();
browserMob.beginStep("Step 1");
 
// rest of test...

In this example, we are allowing all requests to www.example.com and images.example.com to go through, but faking any other request with an immediate 200 response code.

These whitelist and blacklist APIs are just one example of the powerful scripting you can do using the BrowserMob API and scripting environment. We encourage you to review the entire API documentation from time to time, as well as contact us if you ever have questions about them.

Tweet This Post 

3rd party widgets · API · Google Analytics