The importance of online presence continues to grow exponentially. More and more of our personal and professional endeavors are conducted online. Because of this, the ability to ensure a good experience for our online friends and customers also is increasing rapidly.

At its core, load testing is nothing more than ensuring your online presence is ready for the number of visitors you expect. It’s simple to explain, but historically it’s been anything but simple, or easy to afford. Typically load testing was priced according to the number of concurrent visitors you wanted to simulate, and the more traffic you simulated the more the price went up.

However the reality was the cost of the test to the provider didn’t increase nearly as much as the cost presented to the customer. There was a big markup for large tests. What the emergence of the cloud has done is make it easy for the customer to see the actual operational cost of the test, exactly what cloud resources need to be tapped, and to have those passed through with no markup. For example, you can visit the Amazon Web Service EC2 pricing page and see for yourself that they charge $0.085 per hour for a small virtual machine.

I have been greatly encouraged by how this pricing model has caught on, since it lowers the barrier of entry and offer quality load testing to a much broader market. I was recently involved in a load test in preparation for a Super Bowl commercial for an upcoming startup. Using the power of cloud computing, we simulated half a million concurrent visits and transferred over 20 terabytes of data in less than an hour. In the process we spun up over 2,000 virtual machines in the cloud!

Recently, some load testing vendors have modified this pricing approach, and have the customer deal directly with a cloud provider for the operational costs. On the face of it, this seems like a benefit—after all, why not DIY if you can? But in reality, this approach is inefficient and rarely works for even medium-sized load tests.

Here’s why—cloud providers are (quite logically) reluctant to provision significant resources on an ongoing basis unless there is a compelling track record of usage. And the load testing needs of most customers are very episodic. Let’s use Amazon as an example.

The largest number of servers Amazon will provision on demand is 20 servers. Beyond that, the customer must negotiate and convince Amazon that more servers are needed, and that they will consistently need that number of servers. For the large majority of load testing customers, this is not the case. And even if it was, they do not need the added time and complexity of direct negotiations with cloud infrastructure providers.

The best solution for customers is for load testing providers to continue to transparently pass through cloud costs, but also to continue negotiating on behalf of their clients with the Amazons on the world. I know how well the approach works—my company handles load testing for over 800 companies. And because our pricing model passes through the cloud computing costs, our customers can be assured they are getting the best possible value, allowing them to focus on optimizing their site.