Load Impact 2.0 was released at the end of October (27th). The first few days after release were pretty chaotic, with lots of minor issues and some major ones, but having been involved in many big releases during my career I have to say that this one went pretty well actually. The system was up and functional most of the time, the first few days post-release, and that isn't bad at all :-)

Still, there were some difficulties, of course. We had problems first with AMEX payments due to contractual reasons (AMEX payments have been removed for now, until we manage to get through the AMEX bureaucracy) and then with VISA/MC payments. Then there was occasional problems with internal queueing systems that caused some load tests to either fail, "freeze" (get stuck in some state), or never get started. All these issues should have been resolved by now, but there are likely smaller things that will pop up from time to time, so we urge everyone to get in touch with us if you see anything strange happening on the site. Don't hesitate to get in touch with us even if you're unsure whether something is a problem on our side or not, we want to know about all situations where someone has any kind of problem using our service. No issue is too small.

In general, the system is starting to get very stable now, however, and we see more activity than before the release, with more user registrations and more tests being executed. We also see more advanced usage of our service - more people are writing advanced load scripts and running both larger and more complex load tests than ever before. It is all very encouraging and tells us that we are moving in the right direction!

So what is so great about 2.0 then?

Some people may see Load Impact 2.0 as simply an upgrade, but it's more like the launch of a whole new service. It is that much different from 1.0. We have kept some 1.0 key elements that we (and hopefully everyone else) liked such as the ability to run small, simple tests anonymously from our front page, the ability to watch other such anonymous tests that are being run, and the scripting language and scripting API, but behind the scenes most of the code base is new and 2.0 includes a lot of new functionality that didn't exist in 1.0. Here is a small list:

• Large-scale load tests
  As we are now using public cloud infrastructure (Amazon) to generate load test traffic, we have the ability to scale up a load test to a very large size at any of the geographic locations where there are cloud servers available (currently California, Oregon and Virginia in the US, plus Ireland, Japan and Singapore outside the US).
  
  
  
• Multiple user scenarios in a single test
  In 2.0 we introduce "user scenarios". A user scenario defines a certain simulated user category and what that category should be doing on your site. An example can be an e-shopping site that has two types of visitors - one type that just browses the site without buying anything, and another type that registers a user account on the site and then goes on to actually buy products on the site. In Load Impact 1.0 you could not easily combine these two different user categories in a single load test, but with Load Impact 2.0 it is easy - you just create two different user scenarios, that run different load scripts, then you configure your load test to use these two scenarios.
  
  
• Multiple geographical traffic sources
  With Load Impact 2.0 you can now choose to have your traffic originate from more than one physical place, if you want. You can specify any number of combinations of user scenarios (described above) and geographical locations where that particular user scenario should be executed, and create very complex load test configurations where you define that e.g. 10% of the total number of simulated users during the load test should run user scenario X from geographical location Y.
  
  
• More performance metrics
  We now collect more performance metrics than in 1.0, such as "requests per second", and we collect many more sampling points that are all time-based rather than client level-based. This results in more performance data available at higher resolutions than before.
  
  
  
• Much more advanced chart/graph capabilities
  We provide a very dynamic test report page where you can create your own charts and graphs, plotting a wide range of parameters and correlate data with a certain user scenario or test results from a certain geographical region.
  
  
  
• Text-based script editor
  
  For expert users, a text-based scripting editor is usually the best choice, and in Load Impact 2.0 we provide the option to choose between our graphical script editor (LILE) and a text editor that allows easy copy-and-paste and faster code entry for the experienced programmer. Load script programmers now have much more choice in how they create their load scripts.
  
  
• Continuous tests
  Load tests are now executed continuously, which means that a simulated client thread is never shut down as long as the load level is meant to increase. Old simulated clients will just continue execution, reiterating their load script again and again, while more clients are being added. The result is a smoother and more time-efficient ramp-up process than was offered in Load Impact 1.0.
  
  
• Credit based pricing model
  Load Impact 2.0 introuces the credit based model that means there is no difference between one user and the next as regarding them being a "premium" user or not. All users are the same, they just have different amounts of credits, and the ones that have more credits can run larger and longer tests than those who have few credits. This provides several advantages - first of all it allows us to skip all the old limits on how many tests you can run per 24 hours, etc. Now, every test you run consumes credits and only the number of credits you have affects the number of tests you can run. Secondly it means we don't have to restrict access to some functionality to premium users - everyone can do everything on the system, so it is easy to "try before you buy". Thirdly, it makes our product much simpler in general as we only sell one single thing now - Credits - while as earlier we sold access to different premium levels for different amounts of time, making everything a lot more complex. The drawback, however, is that it can be difficult for people to understand exactly how many credits they need to do the testing they want to do. All in all, though, we think the upsides with the credit model are much bigger than the downsides.

We're excited to announce Load Impact 2.0 !

Early spring 2011, we were sitting on a ton of ideas about how to improve Load Impact. We had lots of things on our TODO list for the next few major releases of the service, and were discussing what to focus on first and what our general development road map should look like for the rest of 2011.

We came to the conclusion that incremental updates, that we had been doing so far, was not the best course of action. Some of the changes we wanted to make to the service were dependent on other changes we also wanted to make, and some were hard to achieve on top of the current legacy system. Some parts of old Load Impact we had long been wanting to remake from the ground up, and we realized that this was the time to do it. To break with the old codebase and start a new one, transferring everything we liked from the old code base but not hesitating to throw out anything we did not like.

So we embarked on that long and hard, but also fun, journey. Initially, we aimed to continue updating the old platform regularly, rolling out new features and updates to the live site while developing Load Impact 2.0 in parallel. We soon realized that this was overly ambitious, however, and decided that advanced scripting and the menu-based scripting editor that we released in April would be the last major update to the old Load Impact code base.

Then we spent most of the summer and autumn frantically developing Load Impact 2.0. Since August we have been in crunch mode, working 10-hour days, 6 days a week (which is quite a lot to us lazy and decadent Europeans) and our efforts are starting to pay off now, with the 2.0 platform getting closer and closer to being release ready. At the time of writing we are running a closed beta test, and we expect that to continue for another week or two, then we will take 1-2 weeks to finish off everything, and finally release in the second half of October.

So, what's in it for me?  How will Load Impact 2.0 affect me?

First of all, Load Impact 2.0 is a huge upgrade from the old system. We don't want to spoil the surprise, but it will mean a big step up functionality-wise. We expect our competitors to tear their hair out when they see it, at the very least. Introducing a lot of new features often means that you also introduce complexity, but we think we have made a pretty good job of hiding complex functionality until the user asks for it. Load Impact 2.0 should be as easy to use as (or easier than) the current system.

Introducing Load Impact credits

One big change that we want to announce beforehand, however, is the new pricing model we will adopt in 2.0. So far, we have been selling subscriptions to premium users, letting them buy premium access for a certain amount of time (a day, a week or a month) but we have realized there are several drawbacks to this scheme. For example, people cannot try out all the Load Impact features until they buy a premium subscription. How do they know that they will be able to do what they want to do, if they can't try before they buy? Also, we have to have limits in place on how many tests you can run, how much data you can transfer etc during your subscription period, otherwise we could be hard hit if someone bought e.g. premium access for a month and then ran one test after another, continuously throughout the whole month. So we set limits, and when a user runs one test too many they are told they can't run any more tests. Many people miss these limits, and are upset when they suddenly get denied trying to start a test.

To avoid these problems, and to get a simpler premium product, we have decided to scrap the old time-based subscriptions and instead sell Load Impact Credits. The credits are used whenever you run a load test, with a small test costing less than a large test. Just by having a registered account you will automatically receive a small amount of credits for free every month. You can use these credits to run several smaller load tests, or perhaps one medium-sized test. Per month. If your needs are more frequent or you need to run larger tests, you have to buy extra credits.

We think this system is fair and that it will allow all our amateur load testing users to continue running really small-scale load tests for free, with access to all our functionality, while the professional testers will have to pay for their testing as they often need to run more large-scale tests and sometimes more frequently also.

What will happen with the old system?  Will I be able to access my old test results?

When Load Impact 2.0 is released, we will transfer all users from the old system to the new. We will then also migrate all old test results, configurations etc. The new system will be backwards compatible with the old so you will not lose any data. In fact, there are some test result metrics that we collect today, but which you are not able to see in the user interface (such as how many transactions returned error codes). These metrics will be available in 2.0, even for your old test results.

As Load Impact 2.0 will contain all the functionality (and more) of the current system, we have no plans on keeping the old system running in parallel with the new. When we release, you will not be able to logon to the old system anymore. The web address will still be the same as always - http://loadimpact.com - but the look-and-feel, and the functionality will be different.

What if I have an active subscription at the time you upgrade the site - what happens to my subscription?

Existing subscribers will be given a generous supply of credits, so they will not feel they lost anything by buying a premium account just before the upgrade.

When is the exact date of the release?

We have to get back to you on that!  When the exact date is set, we will email all our users about it.

If you have any more thoughts or questions, don't hesitate to contact us

Our proxy recorder now seamlessly records pages that use the SSL protocol.

One of the most popular tools is the session recorder, which allows you to record a series of actions on your websites and turn it into a loadscipt. No coding is needed whatsoever! However, one issue was that it does not support SSL. In other words, if a login page used the SSL protocol, the user will have to temporarily removed the protocol, perform recording, enable the protocol, change all http to https in the loadscript and then run the test. Well, that's all in the past now! 

We have improved our session recorder such that it enables all recordings on websites that use SSL. Hence, no more tedious updating of the loadscript after recording. You simply record the script which includes entering your login details and once you click "stop recording" the script is generated with the correct URLs.

Below is a test of my.pogoplug.com. As you can see, the script has all the Urls with https at where they should be.

We hope you will give the updated proxy recorder a try and feel free to share your opinion with us!

/Jack

Load Impact has been chosen as one of Europe's 100 hottest companies

This week saw the Red Herring Top 100 Europe awards take place in Paris. Load Impact was one of the 200 finalists chosen to present and on thursday, we were declared to be one of the 100 winners of the prestigious award.

The winners were the companies judged to be the most innovative and to be positioned to grow at an explosive rate. Companies were evaluated on both quantitative and qualitative criteria, such as financial performance, technology innovation, quality of management, execution of strategy and industry integration.

We are of course extremely happy to get even further recognition that we are on the right track. Still, the single biggest positive signal of all is of course, and has always been, our astounding usage statistics. Over 114,000 load tests executed, at the time of writing, is pretty telling. Our users are giving us all the confirmation we could ever ask for, and for that we are ever grateful! We will do our best to live up to all the hype and provide you with the world's best load testing service both now and in the future!

We here at Load Impact are always interested in learning more about browser behaviour, and when we saw Steve Souders new Browserscope project, we really liked it and decided to help out, if we could. Browserscope profiles web browsers, and tries to determine what browsers have support for new features, are suffering from known security issues, or have certain performance-affecting "quirks". It basically runs an extensive test suite on your browser and tells you how good your browser is. Go and check it out, we think it is very cool.

Naturally, we are most interested in the performance-affecting "quirks" browsers have. These mostly fall under the "Network" category in Browserscope (go to browsercope.org and click on the Network tab) and can be stuff like how many concurrent TCP connections a certain browser will open to one and the same host. Internet Explorer 7 will only open max 2 concurrent connections to a webserver, while Internet Explorer 8 will open up to 6 concurrent connections. That means that IE8 can download 6 files at the same time, while IE7 can only download 2 files at the same time. It definitely affects performance, and as such, is very interesting to us (note that the opening of many connections might be a good thing from a client perspective, but worse for the server that has to keep a ton of connections open - we don't advocate opening more connections as a universal way to increase performance...)

We have actually modeled our Web page analyzer on these performance-affecting characteristics that Browserscope has identified for us. Our web page analyzer can emulate different well-known browsers when it analyzes a web page, and the way it does that is by mimicking the behaviours you can read about under the Browserscope Network test category. It emulates browser-specific performance-affecting behavour such as the max number of concurrent TCP connections to open, etc. and thanks to this it can provide fairly accurate predictions of page load times in most major browsers.

Anyway, we decided to try and create a Browserscope test to see what browsers support HTTP trailing headers. This is a feature of HTTP 1.1 that very few browsers have implemented. It means that a server can transmit extra HTTP headers after the HTTP body has been sent. It is useful if, for example, a server generates a large PDF file dynamically and wants to include a checksum (using the Content-MD5 HTTP header), but wants to start sending the file immediately and avoid buffering the whole of the file in RAM. If the browser at the other end support HTTP trailing headers, the server can generate the file while sending it, and while computing the checksum on the fly. Then when the file has been transmitted, the server just add the Content-MD5 HTTP header at the end.

The new test is live at browserscope.org now. It lies under the Network category and is called "Headers in trailers". As you can see, it is only Opera (and Palm Pre!) that seem to support the feature

And now for something really strange

That was a case of finding out whether browsers support a standard HTTP feature or not, but there was also another, more exotic browser characteristic we wanted to dig into. The strange phenomenon that most modern browsers always send Ajax HTTP POST requests as two or more TCP packets. That is, even if the request is small enough to fit into a single packet.

This was apparently first observed by a Yahoo developer, then re-posted a couple of times until Joseph Scott tested various browsers to see which were affected, and found out that most browsers had this tendency, with Firefox being a notable exception. Many have speculated about the possible performance impact of this, and Yahoo have actually incorporated it into their Best Practises for Speeding Up Your Web Site as a separate rule/tip, where they advise people to use GET instead of POST requests in javascript code, because the POST requests may be transmitted using an extra TCP packet. But there is precious little hard data about what this browser behaviour actually does for performance, and we also thought the browser survey done by Joseph Scott was a bit incomplete, so we set out to investigate a bit more.

First, we performed a major survey where we learned that Sea Monkey, Galeon and most versions of Firefox (on various platforms), were the only browsers that sent short HTTP POST requests as a single TCP packet. The rest of the bunch always sent one TCP packet containing just HTTP headers, and one or more TCP packets containing the HTTP body, when a javascript performed an HTTP POST request (note that this  only applies to javascript-generated requests).

Then we wanted to find out how big the performance impact was. We imagined that an Ajax application performing a lot of small HTTP POST requests over a high-latency, high-packetloss link would see its performance deteriorate badly due to the extra time spent resending lost packets, if the user used one of the browsers always sending two packets instead of one. More packets equal more packets lost, which means more waiting for resend timeouts and then more resending of packets.

So, we set up a test bed where we simulated packet loss and network delay between client and server. Then we let the 1-packet browser Firefox compete against the 2-packet browser Safari, to see which one fared the worst. The results were a bit surprising. It turned out that while both browsers saw their average transaction times deteriorate substantially with increased network delay and increased packet loss, Safari did slightly better than Firefox overall. The increase in average transaction time due to packet loss in Safari were not as great as the same increase in Firefox. If you're having a slow day and want more detail, here is a PDF report from the tests.

And you people who aren't very interested in arcane TCP matters can probably stop reading now :-)

Why is sending two packets just as good as, or better than, sending one? I have been discussing this with some networking people on an email list recently, and two possible answers came up:

• if packet #1 sent by Safari is lost, retransmission will occur faster if packet #2 gets delivered, as the receiver will ACK packet #2, whereupon the sender will see that receiver is still waiting for packet #1 and most likely also lower its retransmission timeout for packet #1.
• sending more packets allows TCP to keep better track of network roundtrip times, which are used to set reasonable retransmission timeout values.

What is really interesting here is that the results seem to go against the Yahoo recommendations. There seems to be no discernible performance hit for using POST requests. At least not on the client side. We would love to hear from people who are more familiar with current TCP implementations and who can offer some explanations for this behaviour.