Image © Juja Schneider
When discussing possible load test setups with our clients, we usually need to refer to these key terms: visits, sessions, requests, hits, page impressions, and page views. Actually, we don’t need to discuss all of them, but some are occasionally brought up by the customer, some are requested by us, depending on the context (and complex enough to be discussed in a separate article).
Continue reading Terms explained: Visits, Page views, Sessions, Requests, Hits →
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.