RadView WebLoad 1.3

If the Internet is going to be used for serious business, some serious issues need to be considered. One of these is the ability of a Web server to deliver information at a rate satisfactory to users. These questions are no different from those confronted by database and network administrators on a day-to-day basis, but they now become the Webmaster’s lot.
RadView’s WebLoad 1.3 offers a tool to assist. Used in the quality-assurance stage of a Web site’s development process, WebLoad performs Web site diagnostics to give an indication of how a site will perform before it is rolled out.
Designed to test Web sites for stress, WebLoad enables Webmasters to run and control unlimited numbers of tests generated remotely on networked multiple client workstations against unlimited numbers of Web servers.
WebLoad records calls being requested by and issued to a Web browser. Typically these are requests for a URL or, with a form, a ‘get’ or ‘post command. These calls can be played back in an automated fashion to test the site. WebLoad is intelligent enough to be able to enter data into a form and randomly generate numbers.
Despite the fact that WebLoad claims to test Web application performance, for architectural reasons it is really only able to test Web server performance. A Java application either performs all transactions within the virtual machine or makes a separate socket connection to another application server and performs the direct I/O that way. For this reason, a future release of WebLoad will include a JavaLoad component. Non-Java-based Web applications that access a data-Ixise via a transaction server would need to use traditional client/server testing software like Mercury Interactive’s LoadRunner or Rational’s SQA Suite.
WebLoad operates as a group of programs running simultaneously over several machines. The three main parts are the Load Server (to generate simulated clients that bombard the Web server), the Real Client (to run a single, live client) and the Monitor (to configure a test session and view the results). All machines need to run TestTalk, the network agent.
The Load Server starts and ends simulated client sessions and can simulate from 1 to x number of concurrent users accessing the Web server by manipulating the load size. On the one machine, the Load Server can simulate 10 users running 10 transactions every 10 seconds, or 20 users running 20 transactions every 20 seconds, or 250 users as fast as it can. These numbers can be changed while the test is in progress.
The optional Real Client component provides the opportunity to have real users running on separate machines testing the site from a user perspective.
Using the Monitor program, Webmasters create the test plan either by writing a script or via a point-and-click interface. The test executes user and system-defined timers for clients. The Monitor then communicates with the load server and the live client to get updates, keeping a log of when a request is sent, received, transmitted and completed. Access to the server is measured in transactions per second and in kilobytes per second throughput. This data is presented as reports or graphs and can be viewed in real time. The reports can also be stored to build up a history of the application’s performance.
It is debatable how valuable this kind of information is for an Internet Web site. Very few sites will have 250 users constantly making requests. The nature of Internet usage is to make a request, read a bit, scroll for half a minute, then make the next request. In addition, a large part of a Web site’s performance will always lie out of the Webmaster’s control, which can make the results somewhat misleading. A Web server can only deliver information as fast as the slowest link in the whole Internet delivery mechanism. Because Web servers try to evenly distribute processing between users, this causes a backlog as the server tries to pump information out but has to keep task switching between all the users. If the Web server has been tested to support 1,000 concurrent users over a 10Mbps LAN, it can issue the HTML very rapidly and move onto the next, due to the speed of the LAN. So, while a WebLoad benchmark may assure Webmasters that their server can put out the information fast enough to serve 1,000 users, this result can be quite spurious as the slower links can grind it to a halt.
A workaround would be to make use of the Real Client program with live clients dialling in over the Internet and checking those figures for a more realistic performance.
Given this qualification, WebLoad would be more appropriate for testing intranet sites rather than Internet sites.
WebLoad is available for Windows 95/NT and Solaris. The Monitor
and Real Client stations require a TCP/IP-enabled PC running Windows 95 or Windows NT 3.51 or 4.0. RadView recommends use of a Pentium processor with 16M of RAM and 5M of free disk space. The Load Server requires a TCP/IP-enabled PC with a Pentium 133 MHz (or higher) microprocessor with 64M of RAM and 5M of free disk space running Windows 95 or Windows NT 3.51, or 4.0 or a Solaris 2.4 UNIX-based system with 64M of RAM, 128M swap file, Sparc 5 and up and 10M of free disk space.