Your Final License count is the maximum of two separate requirements: 1) CPU Capacity and 2) Concurrency Slots. The "Bottleneck" column shows which requirement was higher.

1) CPU Capacity (Throughput)

This is the raw processing power required to run all your tests, normalized to an A1 unit (t/s or 'tests per second'). It answers: "Do I have enough *total engine power*?"

Licenses (CPU) = CEILING( Total A1-eq t/s / ( Model_Throughput × Util_Target ) )

2) Concurrency Slots (Slippage)

This is the number of parallel "slots" needed to run your tests within their frequency window. If this number is the bottleneck, you will experience **test slippage**, where tests are delayed until a slot is free.

Example: You have **20 Browser tests** at a 5-minute frequency, and you choose a **2 x A4 model** means 2 instances of A4 each, hence total ndoe capacity is 8 (which provides 2 x 4 concurrent Browser slots, and say each test-depending on single step for this run is taking around 2-3 mins in total including processing, which means 8 tests start in first batch, 8 in second batch). In this specific scenario we were able to run 16 browser tests in this 5 min window instead of mentioned 20, so the last 4 in this specific case slip from the window to next slot (This example is just for representation).

• At 10:00, the first 8 tests run.
• At ~10:03, the next 8 tests will run.
• At ~10:06, the final 4 tests + may be first 4 again will run and so on

The first batch of tests can't run again at 10:05 because the node is still busy. This is **slippage**. The tool calculates the total slots needed and compares it to the model's capacity to determine the license requirement.

Licenses (Concurrency) = CEILING( Total Required Slots / (Model_Slots * Util_Target) )

External Factors to Consider

This tool calculates capacity based on your inputs, but real-world performance can be affected by:

• Target Performance: Slow web pages or endpoints will increase test 'Avg. Duration', which directly increases concurrency pressure and can cause slippage.
• Network/Proxy Health: Network latency or slow proxies add to the test duration.
• Test Options: Enabling 'Debug' or 'Verify' adds overhead and increases both CPU and duration.

Runs per day = 60 / frequency × 24 × tests or steps × nodes.

Test points per run = monitor point weight × network multiplier. Monthly points use 30.4 days, and yearly points use 365 days.

Add-ons follow the workbook values: Hosts 0.2, Zones 0.1, Screenshot 0.2, Filmstrip 0.3, Debug-on-error multiplier 0.2 with a 3% debug rate.

Derived utilization uses tests/hour and Node Processing Time when present. Thresholds: warn@80% and crit@90%.
Error Thresholds: OK < 50/hr, Warn 50-100/hr, Critical > 100/hr.

Memory and instance CPU are used for warning signals only.