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

After 2.0 – what is next?

Post-2.0 updates and plans for 2012

We released Load Impact 2.0 at the end of October, and the reception has been really, really good. We see an increased number of user registrations and more user activity and what is especially fun is to see that people are starting to use Load Impact for really complex load testing of a wide range of different platforms and applications. It seems all the new functionality of Load Impact 2.0 has been very well received and that people are starting to realize its potential, which is great to see for us who have worked so hard in 2011 on getting it out the door.

Right after release we had a number of issues with the payment system, as well as numerous small bugs that only manifested themselves in production, but overall it was a successful release without any major malfunctions. There are still small annoyances left to iron out, but we are making the service better by the day, and also adding new functionality. Here is a list of some things we have done post-release:

 

• Support for new load zone in south america – Sao Paolo, Brazil – and new US West load zone – Portland, Oregon.
• New chart/graph component implemented, providing even more advanced graphing capabilities (e.g. instant zoom)
• Improved help/documentation – customer case studies, load scripting tutorial and example scripts
• Data export functionality added (export to CSV)
• Several problems related to the payment system have been fixed. AMEX support was added.
• Several problems related to test startup have been fixed.
• Credit refund logic for aborted or failed tests has been improved. You now get partial or full refunds when a test fails, for some reason.
• Anonymous tests are run from random load zones.
• Numerous small UI bugfixes/improvements.
• HTTP basic Auth now supported for automatic load script generation.

This list is by no means exhaustive. We update the service every week, usually, with many minor fixes and improvements, sometimes adding new features also. For 2012 we have some much-asked-for features on the road map, such as:

• Improved data parameterization support
  We will implement “data stores” that allow people to upload large sets of data, which will then be made available to them in load scripts. This functionality will make it a lot simpler for people who e.g. have a large list with usernames and passwords that they want the simulated clients in a load test to make use of.
• User-defined metrics
  You will be able to create your own reporting metrics and have your load script store results values for those metrics during a test. Then you can plot graphs for these metrics along with the standard metrics in the reporting (test result) interface. An obvious use for this functionality can be to report load times for individual web pages, in case a user scenario accesses multiple pages (which is fairly common).
• Server metrics
  This is also a power-user type of feature that allows you to import performance data from the web server(s) you are testing and plot graphs of e.g. the CPU usage on your web frontend machine, overlaid with a graph of the average response time for an HTTP transaction. Being able to import server metrics from the machines that are being stressed in the load test provides a much simpler way of correlating information in order to find out where performnce bottlenecks are. Of course, we will support importing data from database servers and other systems your site/application might be dependent on also.

If you have any other features you think we should rather be focusing on, don’t hesitate to tell us about it!  We love feedback.

A merry christmas and a happy new year to you all!