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.

Often when someone wants to test a site that isn’t yet ready for public release, they will use various security measures to keep the general public from looking at it. Sometimes they will use BASIC authentication and other times they will use firewall rules to only allow certain IP addresses access to the site.

However, as we continue to see a growing trend of BrowserMob customers who are deploying websites in the Amazon cloud using EC2, we wanted to highlight that the firewall technique does not work using our service.

Tom Pinckney, co-founder of Hunch, recently prescribed some tips on how to survive being Slashdotted. While Slashdot is no longer the biggest online driver of spikes of traffic, there was a time when it was the king of bringing down sites: a simple mention of a URL on the home page would crush most servers.

These days sites like Yahoo, Digg, and Drudge Report often carry much more weird, but Tom’s lessons apply to any situation where you are going to get a huge spike in traffic (expected or otherwise). There’s a lot of good stuff in Tom’s post, as well as previous one about achieving “consistent performance” that are well worth a read.

BASIC authentication is used to provide minimal, low-security protection from anonymous visitors hitting your website. It is frequently used by companies to ensure that their staging or development environments are not accessibly by the general public prior to pushing the changes to production. Typical authentication dialog prompts look like so:

200912080850.jpg

The challenge here is that this dialog box is the kind of dialog that Selenium cannot automate. You cannot issue “type” or “click” commands on it. In fact, if this box comes up, your script is guaranteed to time out because Selenium will continue to wait for the page to load, not realizing a login is required and unable to populate it.

At BrowserMob we have two different levels of load testing support: one for Real Browser Users (RBUs) and one for Virtual Users (VUs). Often it’s not immediately clear what the difference is and why you’d use one over the other.

RBU Benefits

The high level difference is this: an 100 RBU test means that there will be 100 browsers in the cloud all loading your site and interacting with it, while a 100 VU test means that there will be 100 “threads” issuing HTTP GET and POST requests to your website, but not actually running a browser. This means that RBUs:

We get a lot of customer requests about Flash automation, Selenium, and BrowserMob. Because our load testing and website monitoring services uses real browsers, complete with Flash 10, we can do things no one else can do, like run a load test with hundreds of Flash runtime environments driving traffic on your site.

However, while our infrastructure allows for extremely unique Flash testing support, it’s not perfectly streamlined (yet). While we are hard at work on making Flash support for Selenium and BrowserMob significantly better, at this time some work is required by Selenium users before you can get started.

Like many in the industry, we were surprised and intrigued by the announcement yesterday that Google would be entering the DNS business. The basic logic was clear: Google has a vested interest in the internet being fast, and so they want to offer a free public utility to help it be faster.

Of course, some were doubtful. OpenDNS, probably the company that has the most to lose by this decision, responded quickly. Some questioned its security, while others pointed out that Google gains a lot more than you might think by serving DNS: it would now know everywhere you were going, regardless of whether you went through Google Search or whether the site had Google Analytics installed.

We’re excited about Amazon’s new AWS location. So much so we’ve already started development to bring its benefits to our customers by next week. As such, we had to quickly figure out how to adapt our tools to work with it.

In their announcement, Amazon stated that Elasticfox already worked with the new location. While that’s true, if you tried looking for a new Elasticfox release you’d be in for a surprise: there isn’t one. That’s because it doesn’t need an update to work.

Instead, just fire up your existing Elasticfox installation and click on the Regions button in the upper left corner:

Late last night Amazon released an early Christmas present: a third location for which to run Amazon Web Services. This is important news for BrowserMob customers for two reasons:

  • Monitoring – it will be our fifth location from where checks will run from.
  • Load testing – it will be our third location from where traffic can be generated from.

We are committed to moving at the “speed of the cloud” and as such expect to have both of these options available in the next week. We’re excited about Amazon’s commitment to continue to provide geographic diversity to their cloud offering, and we look forward to their expansion to Asia early next year.

I’m a little late to the party (dynaTrace released their product a couple weeks ago), but I wanted to still highlight their very important tool: dynaTrace AJAX Edition. It’s by far the best browser profiling tool out there – and it’s free!

If you’re familiar with Firebug, then that’ll give you a rough idea of what this product does. However, instead of being a “Swiss Army knife” like Firebug is, dynaTrace did a deep dive on JavaScript profiling.

© 2012 The BrowserMob Blog Suffusion theme by Sayontan Sinha