Modern web-based applications are getting more and more complex, which makes testing those applications very difficult. The web server or client-side javascript can generate unique hidden variables or separate URL paths for each user. Sessions can be specified not just through cookies, but hidden in the web page itself. Values from previous forms can be compressed, encoded, and stored inside variables with names like "__VIEWSTATE". Sometimes even the names of form variables changes from one user to another.
With a scripting-based load tester you'd have to find each dynamic variable and where it is used, and configure it by hand, if it is supported at all. A typical application could have hundreds of dynamic variables, which means developing the test case can take days even if you understand the scripting language. With WPT 2.8 the Application State Management wizard automatically finds and configures each dynamic variable for you. It locates where the variable is first used, and configures a parser to extract that value at runtime, and then detects where the value is used, and configures data replacement so that each virtual user gets its own unique runtime value.
To make things even more complicated, many applications are now using dynamic variable names, where not only do form values change with each virtual user, but the form field names as well. WPT 2.8 is designed to handle even this complicated case with ease.
Many web sites, including e-commerce sites, require the user to login to site using a username and password. Web Performance Load Tester™ supports most authentication techniques, including forms, basic authentication, SSL client certificates and NTLM. Using runtime data replacement each virtual user playing back a recorded business case can log in as a separate user. The Authentication Wizard leads the user through the process of configuring usernames and passwords.
Firefox is gaining more and more marketshare, and WPT 2.8 now allows the configuration of this popular browser as the default. And since Firefox is cross-platform, so is our support, so you can use Firefox on Windows, Linux or Solaris.
Some web applications are meant to be used for long periods of time. Usually the application will have a login at the beginning, and then some sort of repetitive activity that can last for hours. With this new feature the test case will play back the login part of the test case only once, and then the rest of the test case can repeat, accurately simulating the activities of the real user.
Each virtual user behaves exactly as a browser, sending requests to the web server, and then reading back the reply, including error parsing. All of the web pages requested are read back from the web server, keeping open socket connections like a real browser. When combined with the modem simulation and unique IP addresses, this places a much more realistic load on a web server than the typical load tester. Another key feature is "think time", which during a load test simulates the time the user would take to actually read a web page or fill out a form. Because the think times are generated from a recording of a user actually using the site, the think times are representative of what your site will see when it goes live. Of course, all of these features are configurable, so you can choose a combination that best models your user base.
One detail that is often overlooked is the number of simultaneous open sockets used by a browser. Many load testing tools only support a single socket connection per virtual user. WPT opens as many socket connections as the browser during both recording and playback.
You can dynamically vary the number of virtual users hitting your site, so you can see how the performance varies according to load.
You can define transactions that are unique to your business, and group them in new ways to simulate existing or new load patterns. We call these "business cases". This allows the statistics to be gathered in ways that are meaningful to your business. Examples of typical business cases include logging in to a site and making a purchase, performing a search or filling out a form.
In order to simulate the same complexity of user traffic seen on a live web site, you can run multiple business cases at the same time, each with different characteristics. For example, you can have 20% of the simulated users making a purchase, while 60% of the users are looking at product material and the remaining 20% are doing searches.
Its easy to create test cases by simply browsing the web site. All data sent to and from the web server is recorded, including all form variables, usernames and passwords, etc, even with browsing secure sites via https/SSL.
Each recorded test case can then be edited, copied, and pasted or combined into load profiles.
Full support is given for recording from all web browsers on all supported platforms, including but not limited to Internet Explorer, Netscape, Mozilla, Konqueror and Opera.
Web Performance Load Testertrade can run on a variety of platforms, including Windows NT, Windows 2000, and most forms of UNIX or Linux. Please see the supported operating system list for details.
You can view statistics at any level possible in a web site, including the transaction, web page or individual URL level. The statistics collected include:
Web Performance Load Testertrade automatically makes sure each virtual user is seen by your web server as a real, unique user with little or no configuration needed. Each virtual user interacts with a web server's session tracking mechanism exactly the same way as a browser, so your web server can't tell the difference between a real and a virtual user.
Session tracking is configured via a wizard, with detects the type of session tracking in use and leads the user through the configuration process, although in my cases zero configuration is needed.
For application specific items such as user name and password identification, Web Performance Load Testertrade has filters that allow you to easily assign new user names and passwords for each virtual user. The same technique is used to put in unique values for any type of parameter that flows between the browser and server. This flexibility allows us to handle the many different ways of communicating between a browser and web server in order to handle the largest number of configurations. The types of parameters that can be changed at runtime include:
In order to accurately stress test a web server each virtual user must behave like a real user in regards to bandwidth. Each virtual user can be bandwidth limited so that it accurately simulates a user accessing the web site using a variety of modems, including cable modems, or a LAN. This is important because the slower the user's connection to your site, the more I/O buffering is required, and the longer sockets are kept open, all of which affect how your web server is tuned. You can even configure a mix of bandwidths, where 70% of the users are connecting at 56K modem speeds, 15% are connecting at cable modem speeds, and 15% are connecting at LAN speeds.
You have the option of generating virtual users from a single machine or distributing this task among any number of computers. This allows the product to generate very large numbers of virtual users, limited only by the number of computers at your disposal.
In order to get the maximum capability and accuracy for the computer performing the load test, Web Performance Load Testertrade detects at runtime your test computer's capabilities and adjusts the test accordingly. If you're using multiple playback engines, then the controller automatically sends more tasks to the more capable computers.
SSL is a requirement for secure transactions such as online credit card purchases or transmitting
passwords securely.
Web Performance Load Testertrade supports the latest versions of SSL and tested both old and new versions of Internet Explorer, Netscape, and Mozilla on all of the supported platforms. SSL client certificates are now supported as well for authentication.
| Cryptographic Suite | Key Length |
|---|---|
| RSA public key (authentication and key agreement) | 2048 bits (authentication), 2048 bits (key agreement) |
| RC4 (bulk encryption) | 128 bits |
| DES (bulk encryption) | 64 bits (56 effective) |
| Triple DES (bulk encryption) | 192 bits (112 effective) |
| Diffie-Hellman public key (key agreement) | 1024 bits |
| DSA public key (authentication) | 2048 bits |
After running a test, Web Performance Load Tester™'s analysis reports provide quick answers to key questions about your website performance, such as "What was the slowest page on my website", "What was the longest load time for the 'order summary' page?" and "How many users can my website handle?" The Peak Page Duration Report summarizes all the web pages in the test based on the peak (longest) duration recorded for the test run and indicates the time when the maximum occured as well as the number of users running at that time. The User Capacity report determines the capacity of your website based on the selected test results and configurable performance thresholds.
Often the best way to view data is in graph format. Web Performance Load Tester™ has powerful graphing capabilities that allow any parameter to be graphed at any level, so you can view any statistic available in a variety of ways. The results for multiple tests can be graphed, so you can detect changes in performance between test runs. This is great for performance tuning, where you can tweak the configuration of your web server or application server, and see how the changes affect performance.
Sometimes you may need to manipulate the statistics gathered by Web Performance Load Tester™ or run your own analysis algorithms. To support this, data can be exported into most spreadsheets, such as Microsoft Excel or StarOffice or even imported into custom programs. Graphs can also be exported as images, so they can be easy imported into Microsoft Word, Lotus Notes, StarOffice, Word Perfect, Microsoft PowerPoint, etc.
Web Performance Load Tester™ supports Applets and ActiveX components that work through firewalls. The actual applet and ActiveX component themselves aren't tested, since the object of the performance test is to test the web server, not the browsers. Instead, the communication between the component and the web server is captured and then recreated during the testing process.
No matter how your back-end is implemented, Web Performance Load Tester™ supports can capture the interaction between the browser and the back-end and simulate your users. Its been tested with all of the major web servers, application servers, and operating systems. Take a look at our compatible product list for details.




