Load Testing Blog
Load Testing with IPv6 and the RackSpace Cloud
Over in this post, I showed how easy it is to configure IPv6 load testing in Load Tester — it’s all very easy with the possible exception of this part: “you need a load engine with IPv6 connectivity”. If you don’t have IPv6 connectivity from your location with sufficient bandwidth for testing or you need to test from another location, then you will access to a load generator (we call them load engines) with an IPv6 connection. Surprisingly, this can still be a challenge. Indeed, I’m a bit embarrassed to admit that our own cloud engines don’t support IPv6 … Continue reading »
Load testing a website with IPv6 traffic
Are your apps ready for IPv6 users? Many organizations have started to support access to their applications via IPv6 addresses, and along with that comes the need to include IPv6 traffic in the load test plan. Indeed, we recently tested our customer portal to be sure it was accessible via IPv6 (it is – the application is deployed on Google’s AppEngine infrastructure, which includes IPv6 accessibility baked-in).
Of course, before you get to load testing, you should start with a basic connectivity check to ensure your website is accessible from IPv6 routes – you can use a tool such as … Continue reading »
Load Testing Mobile Websites for Android
Load Testing a mobile website has a few key differences from testing the full desktop-oriented version of a website. In this article, I will review those differences and show you how to use Load Tester to create testcases using the stock browser on Android 4 / ICS (the Ice-Cream Sandwich release).
This article does not cover the entire load testing process – I recommend checking out our videos and tutorials for more information on using Load Tester to run and analyze load tests.
Before I jump in, I want to give a quick introduction on how a load test is … Continue reading »
Do NOT cheat on VUs!
Because load testing tools are usually priced by the number of simultaneous users it can generate, it is tempting to lower the think time or increase the simulated bandwidth and run the test with a lower number of VUs than needed. Then, estimate the number of users the system can handle based on this scaling this (flawed) data.
There is a subset of systems for which this is acceptable. These are primarily sites serving stateless static content or very atomic web services on systems extensively engineered for scalability. Unless your system falls into one of these very narrow categories, then DO … Continue reading »
Load Test the Production System
There was a time when the common wisdom accepted that testing a production system was a bad thing. The reasons vary and many still follow that belief. We, however, test production systems for our clients more often than not. Not only can it be successful, we believe it is critical!
We have heard lots of reasons for NOT testing production systems. For example:
It is a 24/7 system, so we can’t take it down.
We can not risk degrading the performance of real users.
We cannot test it live because test data will corrupt the database.
System has to be available 24/7? No need to … Continue reading »
Why you should not cheat on VUs
Because load testing tools are usually priced by the number of simultaneous users it can generate, it is common to use fewer VUs (virtual users) than called for by the test plan. To compensate, testers may lower the think time (the time between pages) in order to move VUs more quickly through the testcases and achieve a higher transaction rate than actual users would produce. The transaction rate may also be increased by raising the simulated per-user bandwidth – again to speed the lower number of VUs through the testcases more quickly. The system capacity must then be extrapolated based … Continue reading »
Simplified pricing for Load Tester 5
Short version:
The pricing for Load Tester 5 has been simplified down to a single price for Load Tester 5, along with a handful of options. Easy to understand, easy to afford, easy to buy!
Long version (or, how I learned to stop worrying and love simple pricing):
We have always tried to make Load Tester easy to understand and easy to buy. Part of that effort was to offer flexible pricing based on what customers needed. Over the years, we increased the number of price tiers, added a variety of permanent, floating and temporary licenses. Somewhere along the way, our price … Continue reading »
Generating 1,000,000 Concurrent Users with Load Tester 5
Can Load Tester really generate 1,000,000 concurrent users? Many of our existing customers have run tests in the 20,000-50,000 range. With previous versions of Load Tester and some internal tools, our services group has run tests as large 600,000 VUs. But none of these tests really pushed Load Tester to it’s limits. We’ve engineered Load Tester from the start to scale, and scale big. All indications made us confident that our load generation infrastructure could scale far beyond any test we had run. However, the UI was not quite up to the task. Controlling the large number of load engines … Continue reading »
Utilize Monitoring Tools During the Load Tests
Load testing tools will report the performance of the system from the end-user perspective – i.e. how long pages take to load in the browser. This information crucial for determining if the site has a performance problem, but does not give a complete picture – it does not tell you why the site is slow. For that, you need performance data from your servers. This will allow you to, for example, correlate periods of slow response time to periods of high CPU utilization. Or find that the number of connections to the database server rises dramatically right before a flurry … Continue reading »
Avoid Contention For Resources
Unless you’ve specifically designed your load test to include them, the most accurate, consistent results will come from tests that do not compete for resources with other processes – particularly sporadic, uneven processes.
If the site’s peak traffic is at 2pm and the least traffic is at 2am, it may be tempting to run your load tests at 2a. Have you checked the backup schedule with the sysadmins? If your backups run at 2:30a, you could spend hours diagnosing strange performance anomalies that could not be reproduced in a second test at 4a. Sounds obvious, right? But it happens all the … Continue reading »