BlazeMeter Credit Types and How They are Charged

Your billing plan is based on one of three credit types: Variable Unit (VU), Variable Unit Hours (VUH), or Tests.

Variable Unit (VU) as Credit

A Variable Unit (VU) is a metric that measures usage of all capabilities across the entire BlazeMeter platform. A VU ceiling signifies the maximum concurrency that you can leverage across the platform as a whole at any time, taking into account various usage metrics such as the number of virtual users, browser session executions, running mock services, mock service transactions, test data usage, and running tests.

Currently, this metric does not yet extend to Service Virtualization or API Monitoring.

Concurrent VUs translate or will translate as follows to the individual parts of the BlazeMeter Continuous Testing Platform:

  • Performance Testing: 1 Variable Unit Hour (VUH) equals 1 VU.
  • GUI Functional Testing: 1 Browser session execution equals 100 VU.
  • Service Virtualization: Each running Mock Service equals 100 VU. Each 2,500 transactions equal 5 VU that is reserved for 24 hours while the Mock Service is running.
  • (coming soon) API Monitoring (also replaces API Functional Testing): 1,000 API calls equals 5 VU (increments of 5 VU are reserved for 24 hours).
  • Test Data: See BlazeMeter Test Data Consumption below.

Variable Unit Hours (VUH) as Credit

A Variable Unit Hour, formerly known as Virtual User Hour, is used to measure Performance testing and GUI Functional testing usage. When using VUH as credit, consumption will be deducted from your VUH credit balance.

BlazeMeter calculates VUH as follows:

Performance testing

In Performance testing, VUH is:

Length of test in hours (rounded up to the next hour) * Max Users

Example:

If a Performance test runs for 90 minutes with 60 virtual users, 2 * 60 = 120 VUH will be billed.

Note that a test's consumption of VUH is based on the actual max concurrency and duration of the test. If you configured a one-hour test ramping up to 20,000 virtual users, but stopped it when it reached 10,000 virtual users, the test would only consume 10,000 VUH. If the test was configured for 3 hours but you stopped it after 2 hours, it would consume the max concurrency reached times 2 (hours).

GUI Functional testing

In GUI Functional testing, VUH is determined by the length of your browser session.

Sum of each browser session in a GUI Functional test:
Length of a browser session in hours (rounded up to the next hour) * 100 VUH

Example:

A GUI Functional test has 2 browsers and 2 iterations with different sets of test data (each iteration runs in a separate browser session for isolation purposes). Each browser session runs for ~5 minutes.

Credits used = 2 (browsers) * 2 (iterations) * 100 (VUH per browser session in 1 hour) = 400 VUH

Note that a test's consumption of VUH is based on the actual max concurrency and duration of the test. If you configured a one-hour test ramping up to 20,000 virtual users, but stopped it when it reached 10,000 virtual users, the test would only consume 10,000 VUH. If the test was configured for 3 hours but you stopped it after 2 hours, it would consume the max concurrency reached times 2 (hours).

BlazeMeter Test Data Consumption

When you use BlazeMeter Test Data features as part of a test execution, you will consume 50% more VU or VUH. You can find the maximum number of test data rows that can be generated for your plan in the plan comparison table.

Example 1:

A Performance test with 1,000 virtual users consumes 1,000 VUH. When you add BlazeMeter Test Data to that test, you incur 50% more in usage, amounting to 1,500 VUH.

Example 2:

A stand-alone mock service processes 5,000 transactions, therefore consuming 52 VU (50 VU is consumed for running the service. Every 2,500 transactions consumes 1 VU more.) If you add BlazeMeter Test Data to it, you will consume 52 VU plus 50%, that is, 78 VU.

Tests as Credit

With this credit type, you will be charged for every test that you run, except for Debug tests that run for 10 users and up to 5 minutes maximum.

Examples:

  • A test runs for 1 minute and generates 10 virtual users/threads. No test credit is billed.
  • A test runs for 10 minutes and generates 10 virtual users/threads. 1 test credit will be billed.
  • A test runs for 50 minutes and generates 500 virtual users/threads. 1 test credit will be billed.

How Many Credits Will My Test Use?

If your billing is based on tests, credits are counted per test, not by duration or number of virtual users or threads. Please note that each test takes a couple of minutes to start up and spin down. An hour-long test runs approximately 55 minutes long, plus time to start up and shut down.

Note: 1 test credit will be deducted from your test credit balance once the test is completed. For multi tests, 1 credit will be deducted as well.

Note: Maximum test duration depends on the plan selected.

If for whatever reason a test failed to run (for example, an error in a user uploaded script) or failed to generate a report (tests need to run for at least 2 minutes to generate a report), the test will not be deducted from your test credits.

Where Can I See My Credit Type?

You can check your maximum concurrency and/or remaining credits, as well as your credit type, by clicking the Cog icon to navigate to Settings > Accounts > Billing. An example billing page is shown next.

Billing.png