The world's best load testing service gets even better!
We have not been very good at updating this blog with all new features and improvements that we have made to the service lately, so this is an attempt to catch up.
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).
- Lowered price for SBUs
SBUs used to cost 0.30 credits per hour, and have now been reduced to 0.24 credits per hour.
- Changed default values for tests
All defaults for test configurations, are now to ramp up to 50 SBU during 10 minutes (previously, an automatically created test configuration would ramp up to 50 SBU during 15 minutes, while a new test configuration created by a user would by default ramp up to 25 SBU 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
- 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)"
- 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
The State of Web Readiness 2012
For the moment we are attending the O’Reilly Velocity Conference in Santa Clara, where we have launched our brand new report “The State of Web Readiness 2012”. In short the report covers how robust sites are based on 8,522 load tests executed in 132 countries. We found out that the average site was load tested at up to 3.4 times the actual capacity. What does that mean? Well the short summary is that a large part of the websites in the world might not stand up to what site owners expect of them.
This is actual data from actual load tests conducted with our own cloud-based online load test tool and frankly, we were a bit concerned with the findings of our study. Not that we are surprised that websites go down when we need them the most. Even though web sites have been a mainstream occurrence for over 15 years, we don’t lift an eyebrow when Apple Store crashes when a new iPhone-model is released. And if even the largest company in the world isn’t able to provide a premium sales channel that performs reliably, then who is, right? It almost seems unavoidable that websites go down. Like a natural disaster you can’t prepare for.
Our analysis indicates something else. After going through 8,522 actual tests we believe that you can be prepared with the right knowledge. The analysis shows that an important factor in the unreliable web is simply overconfidence about how many visitors websites can really handle. If you haven’t done the tests and you still think your website will continue to work unaffected during a hot product launch, a seasonal peak in interest or if you are luckily beeing “slashdotted”, think again!
Have a look at our report here. And we’re looking foward to hear more about what you think about the state of web readiness.
New partner in Benelux
Full press release.
Load Impact 2.3 released!
We're happy to introduce Load Impact 2.3!
Load Impact 2.3 contains a new and improved proxy recorder that automatically detects pages and creates page load time result metrics for each of your web pages. The recorder also allows you to insert code comments in the generated user scenario, which can be useful in order to find where in your user scenario code a certain page is being loaded.
Behind the scenes, Load Impact 2.3 also includes a lot of optimizations that result in a much faster reporting interface, especially for large tests that generate a lot of results data these optimizations will make a huge difference to how snappy the "view test" page feels. And for live tests, the reporting page will also be a lot smoother. In fact, Load Impact 2.3 is a major rewrite of the underlying storage subsystem and how data is being accessed by the user interface code. More things are loaded on-demand now (i.e. as/when needed) and this results in a page that is much lighter on the client computer. You should now be able to view even the largest tests on the flimsiest of laptops.
Other improvements you will find in 2.3 include:
- Graphical editor support for data stores, custom metrics and other new API functionality
- Several API updates - http.page API functions, named parameters, etc.
- You can now plot graphs of load generator CPU and memory usage during the test!
- The URL list on the report page now displays bytes received and compression ratio
- Content type classification now uses the Content-Type header
- Click the pie charts to highlight different objects in the URL list on the test report page
- Many bug fixes...