Today we released a minor update of XLT 4.0. You will find all the details about it at the usual place: https://lab.xceptance.de/releases/xlt/4.0.2/. Check out the release notes too. We mainly fixed some issues around the script recorder, such as start up time and behavior when invisible elements were encountered.
An update of the AWS cloud images will follow in the next hours.
Today we want to give you a small preview of an upcoming XLT feature. Most of you probably know that XLT features agent statistics. These statistics help you to keep an eye on the health of the test execution engines (agents) to ensure that you do not influence the test results by providing insufficient hardware or by applying no or incorrect settings.
Most modern programming languages are virtual machine based and these machines have knobs you can turn to adjust their behavior according to your requirements. XLT runs on Java and so all the things you might have already learnt from tuning your Java-based servers apply to XLT as well. If you do not have experience in tuning your Java-based servers, you will learn a lot that can be applied to your servers and help you to increase performance.
Continue reading XLT – Garbage Collector details visualized
Today, we released XLT 4.0.1. This is an minor update to XLT 4.0 that fixes five defects. Additionally, it provides some documentation enhancements. You can download the release from here: https://lab.xceptance.de/releases/xlt/4.0.1/. At the same location, you will find the documentation as well as the release notes.
We just published four brand-new screencasts about XLT 4.0, its features, and how to work with them. This is our first attempt to use screencasts as a way of documenting our software. They do not replace the written documentation, of course, but they do provide a quick and easy way to become familiar with XLT.
You might be especially interested in the new Script Developer. Our main feature of XLT 4.0.
The script developer is our approach to write and execute scripts efficiently within Firefox. It is a tool to quickly automate web application, share scripts without the hassle of complicated installations, while maintaining full control over possible other ways to execute scripts. The script developer lays the foundation to run test within the browser, execute scripts during builds, create and run test-driven tests, and, if required, export scripts into Java to unleash the power of a modern programming language.
Enjoy the screencasts and of course feedback is always welcome.
There are new public Amazon EC2 images (AMI) available each running 4 agentcontrollers of XLT 4.0.0.r6019 on ports 8500 to 8503. Feel free to use them for your load testing purposes.
The usage of the images is free or charge but you have to pay your AWS usage costs of course. Please keep in mind that you need a valid license to run a load test with more than 5 virtual users.
We just released Xceptance LoadTest 4.0. This release of our load test software got some really nice feature enhancements to make your regression testing easier. So we stick to our general software approach: One tool for regression and load testing. One set of scripts for both purposes.
Continue reading Xceptance LoadTest 4.0 is available
If you write a performance testing software, your first obligation is a performance test for and with that software. So before we can ship XLT 4.0, we have to make sure that it can hold up to its promises. Test software has to be tested too, so to speak. Today we provisioned a bunch of Amazon-EC2 boxes with 30 test agents in total. These charts are from a short test to see where we can get to, when ignoring any target numbers. This was a short and violent test. Just hammer the system under test and see if it can and will recover.
A short ramp up period in the beginning of the test and afterwards we kept a steady load factor. For the steady phase we reached more than 11,000 hits per second.
The target system was seeing about 2,200 concurrent users during the peak of the test.
During that test, the network was transporting about 95 Mbytes/s inbound traffic, this is a network utilization of about 760 Mbit/s. Amazing that the EC2 boxes in the EU data center can handle that traffic. We used just 10 boxes and each box has a 100Mbit network, so the overall limit must have been reached we think.
By the way, the target system recovered easily and was able to serve its normal duties without any problems. But this test clearly showed the limits in terms of throughput. But this test did not show any limits of XLT 4.0, because neither the load boxes in terms of CPU nor the reporting had any problems with this test size.
We just released an update for XLT 3.3. The version 3.3.4 fixes a problem with the onblur event in HtmlUnit that might have led to a recursive loop. More information and the download link can be found in the release notes.
A new Amazon Machine Image (AMI) running XLT has been made available in the EU region. Use the command line tool of version 3.3.3 to discover it. If you want to provision it manually, please refer to
The AMI runs Ubuntu 9.10 64bit with a Sun JDK 6u20. The file limits have been bumped up to permit plenty of sockets for large tests with many users. XLT 3.3.3.r4407 runs on port 8500 and can be used directly. Make sure that your security group includes port 8500 as an open port.
Because I do not know what is the current state of the Java G1 Garbage Collector, I decided to try G1 with JDK6u20. Somehow I was disappointed because after a short moment of predictable GC performance, the entire VM stopped and some major collection was running. You can easily see that in the charts of that run. Right around 20:09:45, the threads were stopped and the entire VM behaved ugly.
So, the G1 is not yet ready for production, of course nobody stated that it is ready for production. If I read the release notes of JDK6u21 correctly, it delivers plenty of G1 changes, so I might try that soon.