The BrowserMob Blog

BrowserMob can support hundreds and thousands of concurrent browsers hitting your website. Because we use real browsers (vs simulating traffic only) this consumes far more resources than any other load testing solution out there. As such our top-end capacity is not necessarily as high as other offerings, though we feel that we can provide enough load for most needs.

See our pricing page for details of our current capacity. If you’re not sure if we can support the capacity you need, try scheduling a test on your own. If we can support it without any human interaction (which is often the case), the test will be scheduled without any warning.

People sometimes wonder how we can charge so much less, especially considering that we’re running real browsers for every virtual user, which costs significantly more than any other load testing technique.

The answer is that we have built an innovative technology that utilizes open source and cloud computing, which allows us to keep our costs very low, despite our higher overhead per virtual user.

What this means in terms of physical location of our browsers is that it’s determined by our cloud computing provider, Amazon. Those locations are:

• Washington, DC (US east coast).

BrowserMob is an external load testing service, meaning traffic originates from outside your firewall. We believe this is the most realistic way to test your web applications, as it properly shows how your site will be perceived by actual end users using real web browsers from external locations, such as their homes or offices. The topic of whether you should test on a production or production-like staging environment is discussed here, so please read that as well.

There are three common approaches if your application is only available internally:

Last Updated: November 18, 2011

Some of our customers want to know the IP addresses of our browsers so that they can allow them inside their firewall for the purpose of testing internally-hosted applications. Because we can support up to thousands of browsers, we can’t possibly list every individual IP address. However, we can share with you the range of IP addresses.

www.browsermob.com

• 63.246.7.217

For our Washington DC location, they are:

• 216.182.224.0/20 (216.182.224.0 – 216.182.239.255)
• 72.44.32.0/19 (72.44.32.0 – 72.44.63.255)
• 67.202.0.0/18 (67.202.0.0 – 67.202.63.255)
• 75.101.128.0/17 (75.101.128.0 – 75.101.255.255)

The concept of a “virtual user” is commonly used in load testing, but the truth is that the definition means different things to different people. Here we will explain what it means to BrowserMob and how you can use them in different ways to test capacity, load, or stress of your application.

In general, a virtual user is exactly that: a virtualize representation of a user, specifically designed to simulate the same behaviors and interactions with your website that a real user would. For example, if you knew that at peak you had 100 real users on your site last year, you could simulate that same behavior with 100 virtual users running one or more scripts that invoke similar navigation and interaction that your real users do.

Because BrowserMob is an external load testing service – meaning the traffic doesn’t originate from your internal network or from the data center where your application is hosted – you might be wondering which can cause potential slowdowns: the code or the network between BrowserMob and your servers?

This is a great question, but before we dive in to it, let’s remember what your users are likely to answer: “who cares!”

Real browsers absolutely matter. That’s why we created BrowserMob! There are two major reasons why real browsers matter:

1. It simplifies the script creation process by letting you avoid all the complexities and hacks you have to do with traditional load testing tools.
2. It ensures that you’ll see 100% of the traffic and load against your site that a real user would cause.

These are fairly complex topics once you scratch beneath the surface. If you’re interested in knowing the detailed reasoning why real browsers help in both of these cases, continue reading.

Simplifies Script Creation

We offer free and/or discounted load tests for qualifying non-profits, open source software projects, and other noble purposes.

With commercial customers, our pricing policy provides two price options: a pay-as-you-go model and an up-front annual subscription model. The subscription model provides a heavily discounted price per virtual user per hour.

If you believe you are going to run more than 2000 virtual user hours in a year (ie: ten 200 user tests for an hour), the discounts you will receive with the subscription package is well worth the investment.

To learn more, please visit our pricing information.

Our policy is simple:

• Any unused credits can always be refunded, no questions asked.
• Any used credits will be refunded with no questions asked if the problem was due to BrowserMob-related issues (service outage, etc)
• Any credit refund from a result of improper usage, neglect, or failure to follow recommendations on our blog and/or documentation will be subject to a case-by-case basis.

The basic premise behind our policy is simple: we don’t want to tie you in or hold you hostage to our service at any time. If there is no cost to us already put in to a load test or an error occurred that was our fault, we’re happy to provide a refund immediately.

Today while browsing the SQA Forums, I found a question very relevant to BrowserMob: should I test on production?

There is no right/wrong answer to whether you should run a test on a production environment. In an ideal world, you’d have a staging environment that is exactly like your production one. But that is rarely actually the case.

Definitely do your initial performance testing internally first. Keep the tests simple and focussed, pinpointing specific parts of the app (certain parts of the UI, the database, etc). Sometimes these tests can be as simple as attaching a profiler (ie: YourKit for Java) to a developer’s desktop and just navigating through the app by hand a few times or playing back a Selenium IDE test 10 times in a row.