New Pay-Per-Test Credits ($1 = 1 Credit)

We recently made two big changes to our pricing.

1. We released monthly subscriptions

2. We converted our test credits to a $1=1 credit model.

If you already had credits in your account before this change, you will notice that the total amount of credits in your account has increased.

Don’t worry, we aren’t a failed state. Your new credit count buys you just as much load testing as you could do before.

We simply wanted to simplify the process of purchasing a single test. Now you can get an exact dollar price for the test you want to run. Easy-peasy-lemon-squeezy!

The price for a single test is based on two factors – load level and test duration.

Head of over to our pricing page to see how it works.

New updates

The world’s best load testing service gets even better!

Yesterday, on Aug 2, we pushed a small update that included the following features and changes:

• Ramp-up restrictions removed
  You can now ramp up or down the number of simulated users in a test as quickly as you like (well, almost – a ramp operation can be done in as little as 1 minute now).
• Ramp steps can be any length
  Previously, a single ramp-up/down step could have a duration of max 120 minutes. This limit has been removed. There is now just a single limit for the whole test schedule, which can be max 24 hours (1440 minutes).
• Changed default values for tests
  All defaults for test configurations, are now to ramp up to 50 VU during 10 minutes (previously, an automatically created test configuration would ramp up to 50 VU during 15 minutes, while a new test configuration created by a user would by default ramp up to 25 VU during 10 minutes).
• New load script API functionality: auto_cookie_handling
  There is now a new boolean option that can be set with http.set_option() – “auto_cookie_handling”. It is set to true by default, but if set to false it will turn off the automatic handling of cookies between requests, allowing the script programmer to design his/her own cookie management.
• Load generator bug fix
  Fixed an intermittent bug caused by issuing sleep statements with sleep time set to zero.

On June 20, we pushed another small update that included these changes:

• Several proxy recorder bug fixes:
  • Fixed problem with injected toolbar appearing in the wrong place
  • Fixed problem with extra HTML added
  • Fixed problem with proxy sometimes generating extra CRLF’s to requests
• New page on site: The state of web readiness 2012
  http://loadimpact.com/readiness
• Company address on invoices
  You now get your company’s address on your receipts/invoices, viewable online at loadimpact.com

On June 8, we released Load Impact 2.4 that contained the following fixes and improvements:

• New load script API functionality
  In this release we introduced a range of new API functions:
  • client.get_user_scenario_name() – returns name of currently executing user scenario
  • client.get_time_since_start() – returns elapsed time since the simulated user started executing
  • client.get_source_ip() – returns the source IP address seen in network traffic generated by this user
  • test.get_name() – returns the name of the currently running load test
  • test.get_time_since_start() – returns elapsed time since start of test execution
  • util.unique() – returns a string guaranteed to be unique across simulated clients in a test
• Extra IP addresses
  You can now configure your load test to use more source IP addresses when generating traffic. This comes at an extra cost as it requires more infrastructure (cloud) resources, but can be very useful for e.g. spreading traffic evenly if you have a load balancer.
• Small UI changes
  Several minor UI tweaks & fixes:
  • Changed “Test title” to “Test name”, for consistency
  • Fixed inconsistent naming of load zones. Load zones are now named as: CITY, COUNTRY CODE (PROVIDER)
    E.g. “Ashburn, US (Amazon)”
• Bugfixes
  • Fixed broken resend email activation link
  • Fixed bug allowing tests to be scheduled up to 1 hour in the past
  • Fixed pagination bug in URL table on test results page
  • Fixed deployment bug affecting graphical editor user scenarios containing Unicode characters
  • Fixed bug causing screen to gray out in certain cases when selecting script editor for new user scenario

Parameterized data, and more

We, are happy to introduce two new, major features in Load Impact that many users have asked for: parameterized data (“data stores”) andcustom metrics.

Parameterized data is when you’re able to provide data in bulk using some common format – often a CSV (comma-separated) file that you upload, and which you can then access from your load script. The typical example is when you have e.g. 10,000 login names and passwords that you want to use in your load test. Entering these by hand into your load script code is prohibitively time-consuming, but with parameterized data you just upload a text file with all the usernames and passwords, and are then able to access these from inside your load script.

Custom metrics is a feature that allows you to store arbitrary result metrics during a load test. A typical use-case would be to store the load time for a certain page on your site (as opposed to just storing the load time for individual URLs/resources on the page). A more advanced use-case would be to fetch server monitoring data (via HTTP) from the web servers that are being tested, and log e.g. their CPU load along with the standard response time data collected by Load Impact. Any metrics stored with our custom metric feature will be visible in the test results interface, and can be plotted as graphs for easy correlation with the standard metrics.

Parameterized data in Load Impact

Parameterized data in Load Impact is implemented using something we call data stores. A data store is basically a two-dimensional array (a “table”) with data that can be shared by multiple clients in a load test. The usage is simple: You create a new data store in the user scenario configuration interface, assign a name to it, then upload a text file with the data you want to insert into it. The data file should be in CSV format (comma-separated values) and be a two-dimensional table, but can contain any number of rows and columns. When you have a data store assigned to a user scenario your load test clients can then use the data store API functions to access the data store, and retrieve data from it.

Further reading: FAQ: How do I use parameterized data?

Custom metrics

Custom metrics allows you to create your own, arbitrary result metrics and store sample points for them that you can then plot in graphs just like any other measurements. Custom metrics are really simple to use – in your load script you just have to call the special functionresult.custom_metric() and supply it with one parameter defining the name of the metric – e.g. “page 1 load time” – and one parameter defining the current measurement value for the same metric (a numeric value). Custom metrics can be used to plot all sorts of interesting measurement data, such as page load times, bandwidth usage for a single URL/resource, time to first byte for new TCP connections, and a multitude of things.

Further reading: FAQ: How do I create my own result metrics?