Client Behavior

The actions of the Web Capacity Analysis Tool Client during a test are summarized in the following list and then described in the paragraphs that follow. During a test, the Web Capacity Analysis Tool Client performs the following actions, in the order presented:
  1. Parse Command Line

  2. Connect to Controller

  3. Receive parsed information from Controller

  4. Spawn specified number of threads

  5. Run for specified time

  6. Summarize statistics for all threads

  7. Send summary statistics to controller

The Web Capacity Analysis Tool client program runs with a single standard parameter which specifies the controller name and an optional parameter specifying the controller port offset. The client attempts to establish a connection to the controller. If the client fails to connect, it continues to retry after 10 seconds. The retry mechanism assures that you do not have to restart clients manually. If a test requires fewer computers than the number of available client computers, the extra clients that fail to connect loop while connected clients execute the test. You can adjust the controller to assure that the right number of clients are connected. After connecting to the controller, the client receives all messages sent by the controller. The controller sends messages to clients in the order in which the clients connected to the controller. When a client has received its messages, the client starts the specified number of threads to perform the raw communication job with the server specified. When the warm-up period ends, the main thread directs all client threads to start measuring performance. The main thread sleeps for the duration of the test, after which it signals client threads to enter the cool-down period. After the cool-down period, the main thread collects statistics from each individual thread and summarizes them. Finally, it sends the statistics message containing the summary to the controller. All client threads are identical. Each thread loops, generating a random number. This random number is used an index into an array listing the class IDs corresponding to the specified distribution. The thread selects a script page from a list of script pages corresponding to the class ID. Then, the thread requests the page from the server. Each page request can involve multiple file downloads or CGI or ISAPI script runs. During the request operation, the thread updates a thread-local copy of the statistics.