The slowest link determines the speed of the system. The assertion came long before the World Wide Web, but the example of the use of web-based systems for more than revealing. Probably, it is difficult to find anyone who visits the Internet and never faced a slow opening pages.
Speed of access to information that prompts the user’s browser, depending on the characteristics of a set of links: query to a database server, the calculations produced by the application server, "employment" web server for a huge load (one million users are already no surprise), congestion of the communication channel and many others. Links in turn consist of smaller parts that can be thus the bottleneck that determines the speed of the system and the user has to wait. But not everyone has the patience of Buddha.
Search for "bottleneck" - a trivial task. Separate modules of the system can operate with no visible abnormalities, and system performance in this case is far from desirable. The perfidy of the weak links in the fact that at low load conditions occur only blunders integration, lying on the surface. In real life begin to fail, even those parts of the system, which did not show much earlier. Often this behavior is caused by problems in architecture. One can easily imagine the consequences of global changes in the final stages of development.
To avoid any unpleasant surprises in the future, it is necessary to test the system performance under load. Several options:
1. Boot the system manually.
Unreasonably expensive: to prepare the jobs, find people (tens of thousands, sometimes hundreds or more) to synchronize their efforts, such as collect and analyze the results. This method should be seen only in exotic cases.
2. Order a testing specialist firm.
Let’s say it’s not cowboy’s office, and quite a worthy organization, in this case:
- Quality testing will be high.
- Will provide all necessary reports for the system under load.
- Made assumptions about the weak points.
- Some additional services.
Method is justified if necessary to make sure that all is well and you can produce the product. If you find any omissions, testing probably need to repeat. If there are many problems, the producer becomes "hostage" of foreign firms. But even in such a situation, the variant is quite acceptable for small firms.
3. Take a free tool for load testing.
Pros - evident from the cons - there is no guarantee of results, lack of customer support (support), works more often than just http.
4. Write your program for stress testing.
Pros - ease of support, the relative ease of changing and refining units, the ability to fit a particular system, nothing more.
Cons - the difficulty of establishing the necessity of testing the tool and its support.
5. Buy a ready tool for load testing.
Suitable option for continuous load testing one or more systems can generate load though every day. The manufacturer takes care of testing the tool and its support and modernization, as well as universality. The licensing system is most often quite flexible, allowing to not pay for "extra" modules.
The last option is the most common among more or less serious companies, the only problem - the choice of the manufacturer.
By the time of writing (2011) on the market there is more than enough load testing tools, including the famous brands: LoadRunner (Hewlett-Packard), Rational Performance Tester (IBM), SilkPerformer (Borland).
All the tools in their own good, but HP LoadRunner 11 appeared protocol, which wants to draw attention. It can be called unique, and even welcome in the area of stress testing. But let us all in good time.
In the early 90’s (first official release of 1989.) Israeli company Mercury Interactive has entered the market with a unique product for those times - LoadRunner (LR), which has long been a leader in load testing.
Historical background: In 2006, Hewlett-Packard bought Mercury Interactive. Now the full name - HP LoadRunner.
LR is able to work with dozens of different protocols, but in light of the rapid development of Internet customers use it primarily for working with web-applications.
This possibility is realized line web-based protocols. First LoadRunner allows you to write a script of user interaction with the application. When you record LoadRunner creates a proxy (using the mechanism hukinga http://en.wikipedia.org/wiki/Hooking), through which you communicate and client-server. At the stage of code generation, another mechanism reconstructs the sequence of user actions. Ready script played with built-in browser.The main web-protocols:
Windows Sockets. "Listens" for traffic and records the activity in the form of incoming and outgoing buffers. Writes the data to the level of TCP / IP «as is". Similarity sniffer.
Web HTTP / HTML. The most popular protocol. Operates in two modes:
- URL-based - uses «HTTP traffic analyze» mechanism, which interprets each buffer in terms of HTTP-protocol (URLs).
- HTTP-based - finds sources of HTTP-requests, using HTML-Parser. The script is a more user friendly.
However, development of web 2.0 technologies makes it difficult to record and play web-scripts (of course, problems arise in all the instruments, not only in LoadRunner). An increasing proportion of operations performed on the client side and listen to the traffic does nothing. In addition, a built-in browser LoadRunner requires extra effort on its completion and support. In fact, to play scripts written for even mediocre web 2.0 sites, you must create a full browser, which implements all the modern standards and technologies used in web development.
To support specific technologies, new LoadRunner protocols: Ajax (Click and Script), Flex, Silverlight, but still the situation with web 2.0 sites, until recently, remained open to question. Many portals are a blend of technology, when records are causing the problems.
The solution is a fundamentally new protocol - Ajax TruClient. He appeared in 11-second version of LoadRunner (Fall 2010).
Historical note: One of the programmers HP fully developed the concept of a new protocol, capable of loading web 2.0 sites, and he himself has realized it in practice! Decision was so successful that currently set up separate teams for its development and improvement. Protocol was tested in two countries (Israel, Ukraine), and in each programmer (connect somewhere in the middle of development), had a few testers to cover the huge amount of modern web 2.0 sites.
Ajax TruClient appears as a separate product, is integrated into LoadRunner, and quite different from any other web-based protocol.
He, like its predecessors, emulates user actions in the browser, but:
- The script is written online - now the user sees the result of each action immediately, without waiting for the end of the recording business process and code generation. Can remove steps, rewrite, and play without having to interrupt the business process.
- The protocol is based on a new approach of automatic object recognition and recording uses a new mechanism.
- At the moment, the protocol works with Mozilla Firefox (version shipped with LoadRunner), play scripts is the "live" browser.
Of course, like every young tool, Ajax TruClient not without flaws - the performance of the protocol depends heavily on the recording site, while that not all technologies can be written only Firefox. However, all this is more than offset by the benefits and huge potential possibilities of a new protocol:
- A three-level interactive writing
- Grouping steps, alternative steps;
- Designs for, if, break, continue, catch error;
- Options: check out the facility;
Ajax TruClient - a new approach for LoadRunner load testing web 2.0. It somehow looks like Windows 7 - a beautiful, comfortable, easy to use. This simplicity, coupled with the ability to easily and fine-tuning the script, save testers from the Herculean effort required to emulate the behavior of web-applications with rich user interface of traditional media.