WO2002086748A1 - Procede et dispositif permettant de tester la capacite transactionnelle d'un site sur un reseau mondial de communication - Google Patents

Procede et dispositif permettant de tester la capacite transactionnelle d'un site sur un reseau mondial de communication Download PDF

Info

Publication number
WO2002086748A1
WO2002086748A1 PCT/US2002/011947 US0211947W WO02086748A1 WO 2002086748 A1 WO2002086748 A1 WO 2002086748A1 US 0211947 W US0211947 W US 0211947W WO 02086748 A1 WO02086748 A1 WO 02086748A1
Authority
WO
WIPO (PCT)
Prior art keywords
agents
load testing
agent
master server
server
Prior art date
Application number
PCT/US2002/011947
Other languages
English (en)
Inventor
Randall A. Hayes
Hunter Ellinger
Original Assignee
Distributed Computing, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Distributed Computing, Inc. filed Critical Distributed Computing, Inc.
Publication of WO2002086748A1 publication Critical patent/WO2002086748A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Definitions

  • the present invention pertains in general to load testing systems for a global communication network and, more particularly, to a distributed load testing system.
  • the global communication network typically referred to as the "internet” has seen an exploding use in recent years.
  • the applications of this network extend from consumer- to-consumer to business-to-consumer to business-to-business applications.
  • An important part of each of these applications is a server which must reside at a given location on the network and monitor incoming and outgoing traffic from the network. This traffic is typically the result of the request sent from a user on the network through the network to the server and, once received by the server, the request is processed therein. The server will then respond with the requested information by relaying it back through the network to the user.
  • the present systems that are provided to load test a server operate to "exercise" the server by residing on the network at remote locations and forwarding requests to the server. These requests are serviced and then the appropriate information returned to the requesting test node. A delay between the request and the receipt of the information by the test node constitutes the delay in the system.
  • the disadvantage to these systems is that they comprise dedicated computers, which are relatively expensive, and are disposed at only a limited number of nodes in the system.
  • the present invention disclosed and claimed herein in one aspect thereof, comprises a method for load testing a customer server on a network.
  • a plurality of agents are provided that are interfaced with the network, each of the agents operable to access the customer service over the network.
  • a master server selects a plurality of the agents on the network as a load testing group.
  • the plurality of agents in the load testing group are activated with the master server to initiate a load test operation of the customer server for a predetermined amount of time.
  • the agents operable are to send the results of the load testing operation thereon to the master server and the results stored at the master server.
  • FIGURE 2 illustrates a detail of a master server and an agent
  • FIGURE 3 illustrates a flow chart depicting the general operation of the interface between an agent and a master server
  • FIGURE 4 illustrates a diagrammatic view of a single agent during a transaction test
  • FIGURE 5 illustrates a flow chart for initiating the load tests
  • FIGURE 6 illustrates a flow chart for the operation of initiating a load test at an agent site
  • FIGURES 7 and 8 illustrate flow charts depicting the load transaction test at the agent and the initiating thereof by the master
  • FIGURE 9 illustrates a diagrammatic view of the manner by which multiple virtual agents are created at a single location
  • FIGURE 10 illustrates a diagrammatic view of a remote customer terminal on the network for controlling the overall operation
  • FIGURE 11 illustrates a flow chart operating at the master customer terminal
  • FIGURE 12 illustrates a display generated at the master customer terminal during load testing
  • FIGURES 13 and 14 illustrate a diagrammatic view of the load testing
  • FIGUREs 15 and 16 illustrate displays of the delay as a function of the request type and the geographic location of the agents
  • FIGURE 17 illustrates a flow chart for the set up operation that configures the load test
  • FIGURE 18 illustrates a flow chart for the agent download operation
  • FIGURE 19 illustrates a flow chart for creating the profile at the master server
  • FIGURE 20 illustrates a diagrammatic view of an alternate embodiment utilizing a calibration agent and a normal agent
  • FIGURE 21 illustrates a flow chart depicting the operation of receiving data from a calibration and a normal agent.
  • FIGURE 1 there is illustrated a diagrammatic view of the system of the present disclosure.
  • GCN Global Communication Network
  • a main customer server 104 is interfaced with the GCN 102 through a port 106.
  • the port 106 represents a plurality of ports 108, it being understood that the main customer server 104 can access the GCN 102 with multiple parallel transactions. This is a conventional configuration.
  • the GCN 102 is also interfaced with a master server 110 which is operable to control and initiate load testing of the main customer server 104.
  • the master server has associated therewith a controller function 112, a dispatcher function 114 and a scheduler function 116.
  • the master server 110 is often operable to control a plurality of agent nodes 118 that are disposed about the GCN 102.
  • the agent nodes 118 are labeled Al, A2, A3,..., AN.
  • Each of the agent nodes is operable to run resident software that can be controlled by the master server 110, which software is operable to create a request, forward that request to the main customer server 104, and then receive a reply.
  • This "transaction” is timed, such that a delay can be measured between the transmission of the request and the return thereof.
  • This delay is a function of the path through the GCN 102, i.e., the time that is required for the main customer server 104 to process the request and the time for the request to be returned back through the GCN 102.
  • each of the agent nodes 118 have a dynamic IP address on the network, the path from the agent to the main customer server 104 may not necessarily be the same path for the return reply.
  • This is the nature of the Global Communication Network 102, in that every communication across the network involves a plurality of intermediate computers on the network. This data communication is typically performed utilizing a defined protocol, such as TCP/IP, a conventional protocol.
  • the master server 110 initiates a load testing by selecting a plurality of agent nodes 118 for the load testing operation.
  • Each of the agent nodes 118 is initiated by a dispatcher 114 in order to receive a request script and instructions as to how and when to play the script to the main customer server 104.
  • This script consists of a plurality of requests in a predetermined order that are to be routed to the main customer server 104.
  • Each of the agents 118 measures a delay between initiation of the script and completion thereof with the completion being the receipt of the final response. This delay is stored locally and, at a later time, transferred to the master server 110. typically, a given agent node may repeat the request multiple times and only send the measured delays back periodically.
  • This information at the master server 110 can then be accessed by the customer, either the main customer server 104 or another remote terminal (not shown).
  • FIGURE 2 there is illustrated a diagrammatic view of the interaction between the master server 110 and one of the agent nodes 118.
  • the agent node 118 has associated therewith a database 202 that is operable to store resident programs therein.
  • Agent 118 is a general computer that resides on the GCN 102 and is basically a personal computer associated with either a business or an individual, this computer having access CPU time that can be utilized. This access CPU time is what is utilized by the master server 110 in order to provide requesting capacity for the load testing.
  • These agents 118 are contracted with by a service provider that operates the master server 110. This service provider provides a contract with the agent 118 that remunerates the agent 118 for the amount of testing that is provided thereby for the load testing operation(s).
  • the master server 110 will provide software to the agent 118 that is disposed as a resident program in the database 202. This resident program typically runs as a process on the agent computer. This process can be initiated by the agent 118 to initiate a ready-to- test command along a status path 204 from the agent 118 over to the master server 110.
  • the master server 110 that recognizes that the agent 118 is in a ready-to-test mode and logs this into a storage location therein. When the master server 110 is ready to begin a load test, it selects among one of the plurality of agent nodes 118.
  • the master server 110 will send an acknowledgment command over a path 206 from the master server 110 to the agent 118 in order to instruct the agent to initiate a load test with the parameters that are downloaded thereto. These parameters instruct the agent as to what type of request to make and where to send those requests. Typically, this is a set of HTTP commands, although any type of network command language could be utilized, such as XML or the such..
  • the master server 110 will basically schedule the load test and, when time for testing occurs, the script will be dispatched to the select ones of the agent nodes 110.
  • FIGURE 3 there is illustrated a flow chart indicating the operation of the interaction between the agent and the master server 110. This is initiated at a block 302 and then proceeds to a function block 304 wherein the agent sends the ready-to- test status information to the master server 110 which is stored therein, as indicated by function block 306. Once the database is updated, an acknowledgment is sent back to the agent 118 that it has been logged into the database. The program then proceeds to an End block 308. This in effect allows the agent or agent nodes 118 to participate on an as ready basis. Therefore, if a multitude of agents are contracted with, then the master server 110 need only have knowledge of which agents on the network have excess capacity that can be used for load testing. Typically, each of these agents will be connected to the GCN 102 over a high speed interconnection such as a DSL line or an ISDN connection.
  • a high speed interconnection such as a DSL line or an ISDN connection.
  • FIGURE 4 there is illustrated a diagrammatic view of the overall operation of the load testing.
  • This load testing is illustrated with a single agent node 118, although it should be understood that a multitude of agent nodes 118 will be utilized in any load testing operation.
  • the load testing operation is initiated by the customer server 104 (or another customer terminal that is interfaced with the GCN 102) by sending in a request along a path "1" from the customer server 104 over to the master server 110 through the network 102.
  • An acknowledgment is sent back from the master server 110 to the customer server 104 along a path "2."
  • the request comprises configuration information instructing the master server 110 as to how the load test is to be run and may even provide a script, if one was not previously set up in the master server 110 as a profile for that customer server 104.
  • the request also provides some scheduling information to the master server 110. [0033] Once the master server has received all of the information necessary from a customer server 104 to initiate a load test, the master server 110 will then schedule this operation in the scheduler 116.
  • the dispatcher 112 Upon the predetermined time for the load test, the dispatcher 112 will contact the appropriate agent node (118) along a path "3" from the master server 110 over to the agent node (118) with sufficient information for the agent node 118 to conduct a load test. As described hereinabove, this constitutes such things as the request or requests to be sent to the customer server 104 and the number of requests to be made, i.e. a start time and an end time. This will be acknowledged by the agent 118 via a path. It should be understood that the master server 110 has a lookup table disposed therein with the ones of the agent nodes 118 that are in the ready-to-test mode.
  • the master server 110 If an acknowledgment is not received back from the agent node 118, this indicates that the addressed one of the agent nodes 118 is not available and it will then be dropped from the list. However, if an acknowledgment is received, then the master server 110 considers this as one of the multitude of agent nodes 118 that are in the load test.
  • the agent node 118 will send an HTTP command or request along a path "5" from agent node 118 over to the customer server 104. This will be processed by the customer server 104 and then returned back along a path "6" to the agent node 118.
  • the agent node 118 will measure the delay between the transmission of the HTTP command and the receipt of a response. It may be that there are a sequence of commands that must be sent in one "script,” the overall delay of that script execution measured as the performance parameter of the system. The script may, and typically will be, repeated a large number of times. Periodically, the delays are averaged and accumulated and forwarded back to the master server 110 over the path "4."
  • FIGURE 5 there is illustrated a flow chart initiating the operation at the customer server 104. This is initiated at a block 502 and then proceeds to a decision block 506 to determine if a log in has been received. Once the customer server 104 is verified at the login, the program will flow along the "Y" path to a decision block 508, wherein it is determined whether a profile is present for the customer server 104, this representing a predetermined script. If not, the program will flow to a function block 510 to create the profile and if not, decision block 508 will flow to a function block 512, the same destination as for the function block 510. Function block 512 indicates the operation wherein the load test is configured.
  • This configuration will constitute such things as the length of time that the load test should be performed, the number of agents that are to be involved in the load test, the location of the agents, etc.
  • the program will then flow to a decision block 514 to determine if the configuration is complete. If not, the program will flow along the "N" path back to the input of block 512 and, when done, the program will flow along the "Y" path to an End block 516.
  • FIGURE 6 there is illustrated a flow chart depicting the operation wherein the master server initiates the operation of the load test at the agent.
  • the program is initiated at a block 602 and then proceeds to a decision block 604 to receive an initiating command. Once the initiating request is received, the program will flow to a function block 606 to receive the various parameters, these indicating all of the necessary parameters to effect a load test by that particular agent.
  • each of agent nodes 18 could comprise a plurality of virtual agents and, therefore, a plurality of parameters may be received to allow each of the virtual agents to operate independently of each other and even operate in different load tests for different customer servers.
  • FIGURE 7 there is illustrated a flow chart that depicts the operation of the run operation on the agent node 118.
  • the program is initiated at a block 702 and then proceeds to a function block 704 to set up a given load testing session.
  • This load testing session comprises the operation of sending requests, waiting for responses and measuring the delay between the time of the transmission of the request to the time of the receipt of the response.
  • the load testing session is ready to execute. This is indicated by a function block 706, wherein an HTTP request is sent out over the network.
  • a timer is started, as indicated by function block 708, and then the program flows to a decision block 710 to determine if a response has been received.
  • the program will continue in a loop until the response has been received, at which time it will flow to a function block 712 to stop the timer and then to a function block 714 to log the delay for the given response.
  • the timer is started to the time it is stopped could involve multiple requests for a given load test. For example, the customer may determine that more than just a simple command is required to test the system. There may be a series of requests and responses that must be transmitted and received in order to determine the load on the system.
  • the program after the response has been logged, will flow to a decision block 718 to determine if more load requests are to be executed.
  • the parameters indicated the number of times that a request script must be executed and the response thereto measured. Until the maximum number has been achieved, the program will flow along the "Y" path from decision block 718 back to the input of the function block 706.
  • the program will flow to the End block 720.
  • the program will flow from the function block 714 to a decision block 716 to determine if this log information should be transmitted to the log. If so, the program will flow to a function block 717 to transmit the log to the master server.
  • FIGURE 8 there is illustrated a flow chart when the master server interfaces with the agent to determine the number of agents and location thereof that are ready-to-test.
  • the flow chart is initiated at a block 802 and then flows to function block 804 to prepare for the session.
  • the parameters are selected for the given load test, i.e., the profile and the configuration parameters associated therewith are pulled up in response to the scheduler determining that the flow transaction is to be initiated.
  • the program then flows to a function block 806 to select the agents that are necessary.
  • agents are selected upon availability, applied geographic location, etc. Once a "poll" of agents has been selected from the internal log, then these agents will be polled, as indicated by function block 808. It is noted that the ready-to-test status was stored in conjunction with the agents ID and their IP address. However, it could be that the agent for some reason went offline, or that the agent's IP address had changed. This change of IP address can occur, since a number of the agents may have what are referred to as "dynamic" IP addresses. These are addresses that are assigned to the agent whenever it accesses its IP server, which then assigns it a dynamic address. As long as the agent 118 does not disconnect with the IP server, then this dynamic address should remain the same.
  • This polling operation will basically address the agent, send information thereto in the form of the session parameters and then update a local poll indicating that this particular agent is participating in the load transaction. Agents that do not respond in the selected ones are then deleted as being non responding, as indicated by function block 810. The program then flows to function block 812 to add new agents and then to a decision block 816 to determine if sufficient new agents have been added. Once complete, the program will flow to a return block 18.
  • FIGURE 9 there is depicted a diagrammatic view of a single agent node illustrating the concept of virtual agents.
  • the agent node 118 has running on its CPU a plurality of separate requesting applications 902 that are each operable to conduct a session over the GCN 102. This is indicated by a plurality of output session ports 904.
  • Each of these session ports 904 represents the ability for one of the sessions 902 to send a request to the GCN and uniquely request information from a customer server and then receive from the customer server a response directed from a request application.
  • FIGURE 9 Also illustrated in FIGURE 9 is the concept that multiple customer servers could be provided, as indicated by a block 906 and a block 908 labeled Cl and C2. It could be that the request application process is 902 labeled Al and A2 interface with Cl, wherein the remaining request applications 902 interface with the customer 908. Therefore, a particular agent node 118 might constitute a thousand virtual agents which can be configured in any manner. It could be that, during a load testing operation where only a percentage of the capacity of a given agent node 118 is utilized, another load test session could be downloaded to the agent node 118 for testing the loading of another customer on the network, or even the same customer by increasing the loading thereto by increasing the number of virtual users.
  • FIGURE 10 there is illustrated a diagrammatic view of the initiation operation, wherein a separate customer terminal 1002 is provided that interfaces with the GCN 102.
  • the customer terminal 1002 will interface through the GCN 102 with the master 110 to initiate and configure the load test transaction. Additionally, the customer from the customer terminal 1002 will have been provided therewith a display 1004 that will enable the customer terminal 1002 to monitor the load transaction.
  • I/O device 1006 such as a keyboard and a storage device, is provided to allow the customer to interface with the customer terminal 1002.
  • This functionality of the terminal 1002 is completely different than that associated with the customer server 104, which is operable to interface with the customers and complete requests over the network 102.
  • FIGURE 11 there is illustrated a flow chart depicting the operation at the customer terminal.
  • the program is initiated at a block 1102 and then proceeds to a function block 1104 to run the set up operation. This, as described hereinabove, is where the configuration parameters are set to the master server 110.
  • the program flows to a function block 1106 to determine if results are to be displayed. If not, the program flows to an End block 1108. If the results are to be displayed, the program flows along a "Y" path of function block 1110 to display the results, which results are transmitted thereto over the GCN 106 by the master server 110.
  • the program then flows to a decision block 1112 to determine if this setup is to be modified.
  • FIGURE 12 there is illustrated an example of a display that might be provided to the customer on the display 1004.
  • the display is arranged in a plurality of rows and columns. There are provided, for example, four columns of data, Dl, D2, D3 and D4. There is also provided a column for Load and a column for Delay.
  • the rows will be dynamically added in real time with the bottom row continually replaced with new data and the upper rows incremented such that the top row will disappear.
  • the data will appear that is necessary to define the transaction, as defined by the customer, and in association therewith will be a "bar" which will indicate the amount of load, i.e., the number of users that are on line in the form of agents.
  • load can be effected by other things than the customer's server, i.e., it could be caused by factors associated with network traffic.
  • load can be effected by other things than the customer's server, i.e., it could be caused by factors associated with network traffic.
  • FIGURE 13 there is illustrated an alternate display of delay versus load.
  • the load i.e., the number of agents
  • the delay can be measured and graphically displayed. It may be that the profile set up or configured by the customer required that the agents be introduced in an exponential manner. As such, the initial access of the customer server by agents would be relatively small and would increase.
  • FIGURE 14 there is illustrated an alternate display and method wherein the load is varied in an incremental manner.
  • a plot of Delay versus Load The Load is initially set to a static value, as indicated by a line 1402 and that is increased at a point 1404 to a second level, a level 1406. It can be seen that the delay will increase to a set level. This can again be increased at a time 1408 to a second and higher level which will result in a delay line 1410. These increments can be actually instituted on the part of the customer by inputting additional commands to the master server 110. This can be increased and decreased at the will of the customer server and in response thereto.
  • FIGURE 15 there is illustrated a display which illustrates the delays as a function of a type of request. It could be that each profile that is run is comprised of multiple different request scripts, there being provided five for the display of FIGURE 15, RQl, RQ2, RQ3, RQ4 and RQ5. It could be that the profile was set up so that there was a certain percentage distribution between the request, where they could be evenly distributed.
  • the request numbers are disposed in one column 1502 with the delay bars disposed in a column 1504 to the right thereof. These are horizontal bars which indicate a level of delay per request. As such, a consumer can have a graphic representation of how a particular request effects the overall delay.
  • FIGURE 16 there is illustrated a display associated with geographical locations of the agents.
  • the agents can be divided into geographical locations referred to as agent locations "AL,” of which there are defined five, AL1, AL2, AL3, AL4 and AL5.
  • AL1 geographical location
  • AL2 AL3, AL4
  • AL5 geographical location
  • the location number is indicated in a geographical location column 1602 with a graphical delay "bar" illustrated to the right thereof in a section 1604.
  • the consumer can gain an immediate graph of a representation of delays as a function of their geographical location.
  • FIGURE 17 there is illustrated a flow chart depicting the operation of configuring the load test, which is initiated at a block 1702 and then proceeds to a function block 1704 wherein the base number of agents, i.e., the minimum is entered.
  • the program then flows to a function block 1706 to determine the increment value, i.e., the number of agents that are added at each increment of time. Also, the increment time is set. In this configuration, which is by example only, the profile determines that agents will be added on at a certain incremental value.
  • the program then flows to a function block 1708 to set the test duration and then to a function block 1710 to set the maximum level of agents that are to be utilized.
  • the program then flows to a function block 1712 to set the type of increment, i.e., whether it is an exponential increment or a linear increment.
  • the program then flows to a function block 1716 to set the profiles. In this operation, as indicated by function block 1718, a selection is made among a number of different stored profiles, such that a mix of profiles or request scripts can be utilized.
  • function block 1720 Once the profiles have been selected for the overall load transaction, the program flows to function block 1720 in order to schedule the load test and then proceeds to an End block 1722.
  • FIGURE 18 there is illustrated a flow chart depicting the operation of downloading the parameters to the agent.
  • the program is initiated at a block 1802 and then proceeds to a decision block 1804 to determine if the scheduled time has occurred. Once the schedule time for dispatching has occurred, the program flows to a function block 1806 to select the profiles that are to be downloaded and then these profiles distributed to the group of select agents, as indicated by a function block 1808. This information, i.e., the agents to which the load test task has been assigned, is logged, as indicated by function block 1810.
  • the responses received from the agents are then logged, as indicated by a function block 1812 and then the program flows to a decision block 1814 to determine if the profiles are to be modified, as indicated by instructions received from the customer terminal. If so, the program will flow along a "Y" path to select new profiles and distribute these new profiles to agents. If not modified, the program will flow along the "N" path to a decision block 1816 to determine if the maximum duration has been achieved, i.e., all of the agents have completed their task. If not, the program will flow along the "N" path back to the input of function block 1812 until the entire load test is completed, i.e., the predetermined number of request scripts have been played by the participating agents. Once complete, the program will flow to an End block 1818.
  • FIGURE 19 there is illustrated a flow chart depicting the operation of creating the profile in the master server 110, which is initiated at a block 1902 and then proceeds to a function block 1904.
  • the program is initiated, this typically being the situation when a new client comes on board, a client is creating a new profile, etc.
  • the program then flows to a function block 1906 wherein the customer creates a profile name.
  • the program then flows to a function block 1908 to determine if the customer wishes to begin playing the request script.
  • the customer will actually send HTTP commands to their browser for a particular transaction. This may require many requests.
  • a customer would access their customer server with a request by directing that request to the URL of the customer server and await a response. When the response is returned, there may be an interactive aspect wherein another HTTP command is returned. This may continue for any number of HTTP commands.
  • the customer will indicate such to the master server 110. This is referred to as the "tracker" operation, which is indicated at a function block 1910, wherein the sequence of requests that are in the created script, are indicated by the function block 1912.
  • the script will flow from a decision block 1914 to a function block 1916 wherein the terminate command will be transmitted by the customer to the master server 110.
  • the master server 110 will then inquire of the customer whether they accept the recorded request script, as indicated by decision block 1918.
  • the program flows to an End block 1920 and, if accepted, the program flows along a "Y" path from decision block 1918 to a function block 1922 to save the script at the master under the named profile. The program will then flow from function block 1922 to the End block 1920.
  • each agent can be comprised of a plurality of "virtual" agents; that is, each agent can be configured to initiate a large number of processes, each process operable to conduct a load test by itself.
  • a large amount of data from a given agent could be output to its broadband network link.
  • This calibration agent is illustrated as a block 2002 in FIGURE 20.
  • the calibration agent is a distinct agent or computer on the network that has access to the network through a single "pipe" 2004. Although illustrated as a pipe, this is merely an internet connection. This could be facilitated with the interface from the calibration agent 2002 computer to a broadband connection such as DSL, which is an interface through an ISP to the GCN 102.
  • This "pipe” refers to the amount of bandwidth that can be accommodated. The larger the pipe, the more data that can be transferred between the GCN 102 and the computer associated with the device.
  • a normal agent is illustrated by a block 2006, which has a "pipe" 2008 disposed between the agent 2006 and the GCN 102.
  • the virtual agents still "load" the customer server, even though the delay measurement may be off.
  • any delay provided by the loading will be reflected more accurately with the calibration agent 2002, since the calibration agent 2002 will not experience delays as a result of overtaxing of its pipe 2004. Since they are bearing the same load test, the delay for the calibration agent 2002 can be utilized for the delay of the normal agent 2006.
  • FIGURE 21 there is illustrated a flow chart depicting the operation of utilizing the calibration agent and normal agents.
  • the program is initiated at a block 2102 and then proceeds to a function block 2104 to receive data from the calibration agents and then to a function block 2106 to receive the data from the normal agents. This data is then compared in a block 2108 and then a determination made as to whether there is a difference, as indicated in a decision block 2110. If there is no difference, the program will flow along the "N" path to function block 2112 wherein both the normal and calibration data are utilized in combination and treated equally.
  • the program will flow along the "Y" path to a function block 2114 wherein a balance will be generated between a normal and a calibration agent data period in one embodiment, the calibration delays will be utilized. In another embodiment, there will be a "blending" of the two values by some predetermined algorithm. After the balanced value has been determined, the program will flow from the function block 2114 to a function block 2116 to log the information, which is also the path that the function block 2112 will take. Once logged, the program will flow back to the input of function block 2104 to continue receiving data on a periodic basis.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé et un dispositif destinés à tester la capacité transactionnelle d'un site sur un réseau mondial de communication. Une pluralité d'agents (118) font interface avec le réseau, chacun de ces agents (118) permettant d'accéder au serveur client (104) sur ledit réseau. Un serveur maître (110) sélectionne une pluralité d'agents (118) sur le réseau sous la forme d'un groupe de test de charge. Les agents (118) dans le groupe de test de charge sont activés avec le serveur maître (110) en vue de lancer une opération de test de charge du serveur client (104) pendant une durée prédéterminée. Les agents (118) permettent d'envoyer les résultats de l'opération de test de charge vers le serveur maître (110) ainsi que les résultats stockés au niveau du serveur maître (110).
PCT/US2002/011947 2001-04-18 2002-04-17 Procede et dispositif permettant de tester la capacite transactionnelle d'un site sur un reseau mondial de communication WO2002086748A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US83703001A 2001-04-18 2001-04-18
US09/837,030 2001-04-18

Publications (1)

Publication Number Publication Date
WO2002086748A1 true WO2002086748A1 (fr) 2002-10-31

Family

ID=25273312

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/011947 WO2002086748A1 (fr) 2001-04-18 2002-04-17 Procede et dispositif permettant de tester la capacite transactionnelle d'un site sur un reseau mondial de communication

Country Status (1)

Country Link
WO (1) WO2002086748A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014148667A1 (fr) * 2013-03-22 2014-09-25 엔에이치엔비지니스플랫폼 주식회사 Système de test pour la réduction du coût de test de performance dans un environnement nuagique et méthode de test associée
CN105007233A (zh) * 2015-07-13 2015-10-28 互联网域名系统北京市工程研究中心有限公司 一种基于dhcp服务器集群负载分配地址的方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014686A (en) * 1996-06-21 2000-01-11 Telcordia Technologies, Inc. Apparatus and methods for highly available directory services in the distributed computing environment
US6212560B1 (en) * 1998-05-08 2001-04-03 Compaq Computer Corporation Dynamic proxy server
US6269330B1 (en) * 1997-10-07 2001-07-31 Attune Networks Ltd. Fault location and performance testing of communication networks
US6314463B1 (en) * 1998-05-29 2001-11-06 Webspective Software, Inc. Method and system for measuring queue length and delay
US6317789B1 (en) * 1995-08-22 2001-11-13 Backweb, Ltd. Method and apparatus for transmitting and displaying information between a remote network and a local computer
US6317786B1 (en) * 1998-05-29 2001-11-13 Webspective Software, Inc. Web service
US6327620B1 (en) * 1998-05-28 2001-12-04 3Com Corporation Methods and apparatus for collecting, storing, processing and using network traffic data

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317789B1 (en) * 1995-08-22 2001-11-13 Backweb, Ltd. Method and apparatus for transmitting and displaying information between a remote network and a local computer
US6014686A (en) * 1996-06-21 2000-01-11 Telcordia Technologies, Inc. Apparatus and methods for highly available directory services in the distributed computing environment
US6269330B1 (en) * 1997-10-07 2001-07-31 Attune Networks Ltd. Fault location and performance testing of communication networks
US6212560B1 (en) * 1998-05-08 2001-04-03 Compaq Computer Corporation Dynamic proxy server
US6327620B1 (en) * 1998-05-28 2001-12-04 3Com Corporation Methods and apparatus for collecting, storing, processing and using network traffic data
US6314463B1 (en) * 1998-05-29 2001-11-06 Webspective Software, Inc. Method and system for measuring queue length and delay
US6317786B1 (en) * 1998-05-29 2001-11-13 Webspective Software, Inc. Web service

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014148667A1 (fr) * 2013-03-22 2014-09-25 엔에이치엔비지니스플랫폼 주식회사 Système de test pour la réduction du coût de test de performance dans un environnement nuagique et méthode de test associée
KR101461217B1 (ko) 2013-03-22 2014-11-18 네이버비즈니스플랫폼 주식회사 클라우드 환경에서의 성능 테스트 비용 절감을 위한 테스트 시스템 및 테스트 방법
US10230613B2 (en) 2013-03-22 2019-03-12 Naver Business Platform Corp. Test system for reducing performance test cost in cloud environment and test method therefor
CN105007233A (zh) * 2015-07-13 2015-10-28 互联网域名系统北京市工程研究中心有限公司 一种基于dhcp服务器集群负载分配地址的方法
CN105007233B (zh) * 2015-07-13 2018-02-27 互联网域名系统北京市工程研究中心有限公司 一种基于dhcp服务器集群负载分配地址的方法

Similar Documents

Publication Publication Date Title
JP5179359B2 (ja) ネットワークに接続されたサーバ・クラスタ内のクライアント・セッションの動的リバランシングを行う方法及びシステム
USRE42153E1 (en) Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US7254607B2 (en) Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US8380843B2 (en) System and method for determining affinity groups and co-locating the affinity groups in a distributing network
US6601020B1 (en) System load testing coordination over a network
CN100409219C (zh) 启动服务入口的自动控制模块
US20020007338A1 (en) Method and apparatus for conducting a bidding session
US6732146B1 (en) Information processing apparatus, information processing method, and information providing medium providing a changeable virtual space
KR100551454B1 (ko) 서버의 응용프로그램 성능을 시험하기 위한 그리드 컴퓨팅제어방법 및 그 서비스방법
US8204993B2 (en) Computer system and information processing method
US9052941B1 (en) Automated testing of online functionality providers
CN102708173A (zh) 处理用户访问网页的请求的方法及系统
CN107733995A (zh) 一种会话保持方法、装置和电子设备
US20040199633A1 (en) Distributed computing system using computing engines concurrently run with host web pages and applications
US20020178264A1 (en) Secure creation and distribution of instructions to uniquely support network applications
KR20000030465A (ko) 네트워크 기반의 실시간 경매 및 역경매 시스템
US20080228859A1 (en) Grid Computing System for Testing Application Program Capacity of Server
WO2002086748A1 (fr) Procede et dispositif permettant de tester la capacite transactionnelle d'un site sur un reseau mondial de communication
US7117506B2 (en) Plug-in API for modular network transaction processing
CN110738554A (zh) 任务处理方法、装置、电子设备及计算机可读存储介质
US20040254828A1 (en) Information offering apparatus, information offering method, program and product
WO2019051267A1 (fr) Publication fondée sur un réseau et distribution dynamique de contenu multimédia en direct
JP4728026B2 (ja) 負荷分散システム、および負荷分散方法
US10311502B1 (en) System for limiting and controlling access to limited resources over a network
KR20020024356A (ko) 인터넷 쇼핑몰 운영 시스템 및 그 운영방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION PURSUANT TO RULE 69 EPC (EPO FORM 1205A OF 300304)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP