Synthetic Monitoring
Creating a well-crafted website that’s popular with the everyday user is just like creating a great roller coaster. It has to be able to handle unexpectedly large crowds, the experience has to be one that brings users back time and again, and it has to simply run – no slowdowns, no hiccups and please, oh please, no crashes. Just as a roller coaster has to be tested with a real-world load to ensure it can hold up, a website also has to be tested to ensure that it can handle loads properly.
One method designers use to handle the load and keep the website running is to include load balancing in their design. Load balancing the web application across several servers to provide adequate capacity and seamless redundancy is a common technique, but load balancing can be used across multiple tiers of the website design, including having multiple database servers (all staying synchronized) and an array of servers running the business logic that supports the web application. Because these deeper layers serve the user interface, they are harder to exercise and need sophisticated testing to ensure that all layers of a website are able to handle the load and that the load is being distributed appropriately and according to its design.
Whether your load balancing scheme is a simple round-robin method, or it requires a complex algorithm that measures the number of active connections and the load on each server, the best way to exercise and test your design is by way of Synthetic Monitoring and Scripted Testing. Building test scripts that exercise your code fully, including embedding URLs that trigger calls to all components of your environment, allows you to take snapshots and gather long-term test data to see how well your load balancing techniques are working. Targeting the parts of your environment that you feel are weak points can be as simple as capturing transactions in real-time and transforming them into scripts through your test tools.
At the same time, testing your load balancing schemes and finding out whether your Business Process loads are being distributed properly at both the ingest from the User Interface and at the egress to supporting applications and databases requires generating scripted loads at levels that are greater than those you expect in the real world. This also means generating staggered loads, with spikes and valleys that mimic worst-case scenarios your website will face.
Your test tools must give you the capability of capturing real-world transactions and turning them into test scripts that you can deploy across thousands of users. They should give you the ability to generate real-world levels of requests at real-world intervals. If your tools don’t, or if they’re just too complex to do it easily, you should look into Apica Load Test as the way to turn a difficult scripting scenario into an easily-built, easily-modified scripted test tool to put your website through its paces. That way, when changes to your website go live, you can simply enjoy the ride.