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!”

We don’t really mean to give such a flip answer, but we’re trying to highlight the important fact that at the end of the day the user doesn’t care if his ISP, your ISP, your database, or your code is the root cause of a slowdown. All he cares is that his visit to your site met his expectations.

Of course, that doesn’t mean you shouldn’t care where slowdowns are happening, since knowing the root cause is likely the only way to fix the problem. So how can you tell where the problem exists?

Currently, BrowserMob only can tell you what the performance looked like from the browser/end user’s perspective. We can tell you how fast or slow page load times were, if AJAX calls started taking longer as you added more concurrent sessions, or if images were loading slower or faster compared to stylesheets. But we can’t directly tell you why or where the slowdown occurred.

There are a few things you can do directly with BrowserMob:

• Schedule smaller tests. Don’t just run one large test. It may be that a small software glitch or system configuration is causing your site to slow down, so running several progressively larger tests will help you identify issues sooner and will likely save you money in the long run.
• Use the ramp feature. By ramping from 0 to 100 users, you can see what performance looks like with very few users and compare it to many users.
• Schedule multiple phases with ramping and constant levels of load. By putting some constant load in as well, you can get a “baseline” at different load levels and compare it to other baselines.

There are also a few things you can do outside of BrowserMob:

• Run two baseline tests Selenium IDE and a stopwatch: one from the local network where the server is located and one from a remote location (such as your home or remote office). This will give you a general idea of what the “network overhead” is.
• Work with your developers and database administrators. If possible, get them involved early and often during a load test. They can usually add some logging or profiling code that can pinpoint the exact problem.
• Know your network infrastructure. Knowing what throughput the environment can handle under test will help you know if your test has saturated the physical limits of the network. You can compare this data to the BrowserMob throughput chart.
• If you have any systems monitoring solutions, use them during load tests. Tools like Hyperic are great for telling you when the CPU or RAM usage goes critical on various machines, such as your web server and database server.

We should also note that we’re hard at work on some new features that will make your job of monitoring internal and external metrics much easier. Please stay tuned!

Tweet This Post 

No tags