The first thing that you'll likely be confused and possibly intrigued about is the way we handle pricing at Flood.
Through our experience, we found that the classical approach of charging per Virtual User (VU) just didn't map to the reality of how you do testing, which is to say it is an iterative process and often results in a few test fires and misses in the beginning.
We believe that you shouldn't be paying the same amount for miss firing tests because we're not delivering the same value to your business as we do when your tests run correctly.
Introduction and terminology
We designed Flood's pricing to be aligned with our underlying costs, which are the servers that we distribute your tests on, collectively called Grid nodes.
Which raises the immediate question of "How many nodes do I need?", and the answer is, "it depends".
First of all, let's make some assumptions; You want to simulate 5,000 users load for 1 hour.
Before running anything, we typically say that with JMeter and Gatling, all things being equal (network latency, throughput, server speed, etc.) that you'll be able to achieve the load of 1,000 users per node — this is our typical planning figure.
For Selenium it is much lower at 5 users per node due to the large memory and CPU footprint of running full browsers.
So for our test, we'll run five nodes, with 1,000 threads each, representing 5,000 total users.
Approach 1: A single node test for free
The easiest and cheapest approach is to run a single node test for free. Each free account lets you try up to 5 grid node hours for free.
Once you have completed a Flood on your Grid, review your results. If you achieved less concurrency than planned, it is likely that your test script is too complex or target site performance is poor. (If this is the case, our blog has tips on tuning each load testing tool.)
If your test performed as intended, you can assume that you've picked a good planning figure and you can scale out from here. Flood's infrastructure is decoupled by design and can scale linearly out to 90 nodes per grid without any performance penalty with as many grids/regions as you need.
Approach 2: Going all in
Sometimes you're confident that you've got a good starting point with the test scripts at hand, typically from running them locally on your development machine.
In this case, we suggest firstly upgrading to a paid plan, and then launching five nodes in a Grid, in your region of choice.
Once you have a Grid starting, you can create a Stream to launch your Flood from.
Configure the Load Generation tool to run 1,000 threads per node, for a duration of up to an hour (if your Grid is running for an hour, less or more as you desire) and click Launch Test.
Once you have results, compare the concurrency to your desired load.
If your results came in below, then you might consider running fewer threads and more Nodes or optimising your test scripts by removing unnecessary assertions.
Scaling out
Once you have a planning figure, you can scale out your load as needed to any amount by multiplying your baseline figure by the number of nodes you want.
You can split the load between multiple regions to simulate peak user load across coasts or continents.
How much will this cost?
We charge per node per hour. That is, if you run a Grid of five nodes for one hour, it will cost you five node hours.
We bill nodes in 15-minute blocks so that you can run them for any duration from 15 minutes, up to 48 hours.
Choosing a plan
If you're only going to run a handful of one-off tests, then a PAYG or Standard Plan will probably suit your needs. If, however, you've calculated from the above tutorial that you'll need more hours, we offer plans up to 400 hours per month or more as needed.
Overages are charged at our PAYG rate once you exhaust the hours included in your plan unless you upgrade to a larger plan.
All plan changes are pro-rated for the month of change.