We strongly believe that trying to force a test effort into neatly contained monthly or annual subscriptions just doesn't work. Performance testing is an exploratory thing. It's not uncommon to stop, start, break, fix and restart in an ad hoc fashion. That's why we've priced everything competitively by the hour to afford you the most flexibility in testing. No long term commitments, no contract lock-in, just pay as you go, on demand.

Given most of our customers are in Australia, it made sense for us to support AUD during the beta. If the Grid becomes insanely popular we'll consider options to provide payments in USD as well.

Of course! Our Grid nodes are powered by the latest JMeter binaries and JMeter-Plugins. Everything runs headless so we advise not using any listeners in your test plans, as we take care of the number-crunching-munging for you.

Indeed you can. All of the test result data can be exported using our simple API. Look for the export functions in JSON or CSV format for each of our graphs and build your own.

It certainly does. We've been careful to build the Grid on components that scale. We've also removed most of the dependencies that you might see in other load testing solutions, particularly with clunky distributed interfaces such as RMI found in JMeter. Each Grid node is fully autonomous and sits on its own instance of Elasticsearch. Grid nodes can be clustered by geographical region offering you peak performance whilst still being able to analyse and serve up load test results. The only limit is the cloud on which you deploy the Grid... how many instances can you spin up?

This is one of those 'it depends' answers. If you've been load testing with JMeter for a while you will know that you can get varying levels of performance from a single JVM. That performance depends on things like how complex your test plan is in terms of how many samplers you use, transaction throughput, use of timers, listeners or other resource intensive operations. If your test plan is just a simple thread group plus sampler kind of thing, then it's not unreasonable to get a thousand users from a single instance. If you choose to use Gatling, you can get many thousands of users from a single instance. Provided of course you don’t saturate network, disk or CPU in the process. The best way to tell is to try a single Grid node with your test plan and monitor its performance under load.

All our Grid nodes are the equivalent of an Amazon EC2 m1.xlarge instance. That is a whopping 15 GB memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each) on a 64-bit platform running Ubuntu.

All our Grid nodes are available from standard Amazon EC2 regions in the US, Europe, Asia Pacific, South America and Australia.

We don't! This was a deliberate decision by us to remove 'centralized' dependencies and make Grid nodes a truly disposable cloud asset. We also think this will make Gridinit survive the distance by lowering our running costs and offering truly competitive pricing. Each private Grid node you purchase is autonomous and stores its own test results from any tests excecuted on it. If you purchase more than one private Grid node in the same geographical region, they will automatically cluster the results amongst themselves. As long as one of those Grid nodes remains running, your results will be retained. If you wish to persist test results we advise you extract data from your Grid nodes using our export functions.

Certainly. All of our Grid nodes are monitored under load, and we provide an indicator of health in terms of services running and 5 minute load average for each node. If anything is unhealthy, it'll be flagged with a notice letting you know. Alternatively you can view performance of any Grid node at any stage using monit.

We'll be blogging regularly with tips and tricks. You might like to read our Getting Started guide. Follow us on twitter @gridinit or contact us via email at support@gridinit.com