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.
For example, suppose during peak time your site got 4 visitors over a specific an hour, as demonstrated here:
While you received four users in an hour, you only received three concurrent users at most (V1+V2+V4 and V2+V3+V4). So this would mean the max concurrent users you have seen is three, and that should probably be the benchmark and/or baseline in which you do your load testing around, depending on your goals.
In BrowserMob, a virtual user is a dedicated web browser that is ready to play back a pre-recorded script one or more times endlessly. It’s very important to understand that a virtual user == a web browser and that the browser will repeat the script endlessly until the test ends or the number active virtual users are turned down. This means that if you scheduled a load test that ramped from zero to three users over an hour long period, the load profile might look like the following:
In other words, with three virtual users, you might see the overall visits be closer to five or six. This means that when planning out your load test, it’s important to think about total visits/sessions as well as concurrency. Usually concurrent is what people are most interested in, but sometimes sessions are very important too. By remembering that a “virtual user” in BrowserMob replays the script over and over again, you can properly plan out the expected concurrency and total sessions.
This often means that if you aren’t worried about total sessions but instead just the raw hits/traffic that they cause, you can usually use far less virtual users than you might initially have thought you needed. In this example, we could likely use two browsers/virtual users and achieve the same number of visits we saw in the real world.
This topic is a very broad topic, and often related questions come up, such as the difference between load testing and stress testing which is more important: hits or concurrent users. Please see our FAQ and our blog for a full list of related questions.
Recent Comments