Abstract:
A method for determining the performance of a first processor in a computer network in which the first processor is connected to a second processor includes incrementing a request count when the second processor requests data from the first processor, incrementing a reply count when the second processor receives data from the first processor, dividing the reply count by the request count to create a ratio and indicating the performance of the first processor is less than expected when the ratio is less than a threshold. An apparatus for determining the performance of a first processor includes at least one memory having program instructions and at least one processor coupled to the first processor. The at least one processor is configured to increment a request count when the at least one processor requests data from the first processor, determine the performance of the first processor based upon a reply count and the request count and increment the reply count when the second processor receives data from the first processor.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to computer science. More particularly, the present invention relates to fault tolerant client-server environments. 
     2. Background 
     Many organizations have a substantial number of computers in operation, often located far apart. For example, a company with many factories may have a computer at each location to keep track of inventories, monitor productivity and do the local payroll. Connecting these computers via a network enables resource sharing by making all programs, equipment and especially data available to anyone on the network without regard to the physical location of the resource and the user. 
     Reducing the cost of computing is important. Small computers have a much better price/performance ratio than large ones. Mainframes are much faster than personal computers, but they cost significantly more. This imbalance has caused many systems designers to build systems consisting of personal computers, one per user, with data kept on one or more shared file server machines. In this case, the users are the clients, and this type of arrangement is referred to as a client-server architecture. 
     Turning now to FIG. 1, a block diagram that illustrates a typical client-server architecture is presented. Client  10  is connected to a server  12  via bus  14 . Communication typically takes the form of a request message  16  from the client  10  to the server  12  asking for some work to be done. The server  12  then does the work and sends back a reply message  18 . Typically, there are relatively many clients using a relatively small number of servers. 
     Reliability and availability are important features in client-server computing environments. Computer networks increase reliability by having alternate sources of supply. For example, all files may be replicated on multiple machines, so if one of them is unavailable (due to hardware failure or communication failure), the other copies may be used. In addition, the presence of multiple processors means that if the performance of a particular processor degrades sufficiently, the other processors may be able to take over at least a portion of its work. 
     Reliability and availability are especially important for applications that perform critical transactions. Such applications include military, banking, air traffic control, nuclear reactor safety and many other applications. In these cases, the ability to continue operating in the face of hardware or communication problems is of utmost importance. Servers in these systems typically must be fault tolerant. For instance, if the primary server is functioning poorly or not at all due to a heavy workload or network problems, a backup or secondary server may be invoked to assume the server workload, thus allowing critical transactions to continue without undesirable interruption. 
     Typically, the client in a fault tolerant system detects an improperly functioning server by monitoring communications between the client and the server. One typical fault tolerant algorithm requires that the client record each request it sends to the server. The client stores a specific number of recent requests into a buffer and relates any reply received to its respective request. This method requires a mechanism to uniquely identify each request and each reply. Typically, a separate task is activated periodically to check the delays and reply-request ratio, which is the number of replies received from the server divided by the number of requests sent to the server. If replies are received with large delays, or if the reply-request ratio is too small, deteriorating server performance is indicated. 
     This method of logging messages and associating each reply with a specific request increases the complexity and memory requirements of fault tolerant systems. This problem is exacerbated in modern client-server systems in which a single client is connected to many servers, requiring separate fault tolerant checks for each client-server connection. 
     Accordingly, a need exists in the prior art for a method and apparatus for a robust fault tolerant client-server system that requires relatively little processor and memory overhead. 
     BRIEF DESCRIPTION OF THE INVENTION 
     A method for determining the performance of a first processor in a computer network in which the first processor is connected to a second processor includes incrementing a request count when the second processor requests data from the first processor, incrementing a reply count when the second processor receives data from the first processor, dividing the reply count by the request count to create a ratio and indicating the performance of the first processor is less than expected when the ratio is less than a threshold. An apparatus for determining the performance of a first processor includes at least one memory having program instructions and at least one processor coupled to the first processor. The at least one processor is configured to increment a request count when the at least one processor requests data from the first processor, determine the performance of the first processor based upon a reply count and the request count and increment the reply count when the second processor receives data from the first processor. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram that illustrates a client-server architecture. 
     FIG. 2 is a block diagram that illustrates a computer network according to one embodiment of the present invention. 
     FIG. 3A is a state diagram that illustrates a method for determining the performance of a server in accordance with one embodiment of the present invention. 
     FIG. 3B is a flow diagram that illustrates a method for determining the performance of a server in accordance with one embodiment of the present invention. 
     FIG. 4 is a flow diagram that illustrates a method for determining the performance of a server in accordance with one embodiment of the present invention. 
     FIG. 5 is a flow diagram that illustrates a method for determining a server status in accordance with one embodiment of the present invention. 
     FIG. 6 is a flow diagram that illustrates a method for determining a server status in accordance with one embodiment of the present invention. 
     FIG. 7 is a block diagram that illustrates the timing relationship of send and receive messages. 
     FIG. 8 is a flow diagram that illustrates a method for determining a server status in accordance with one embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Those of ordinary skill in the art will realize that the following description of the present invention is illustrative only. Other embodiments of the invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. 
     This invention relates to computer science. More particularly, the present invention relates to fault tolerant client-server environments. The invention further relates to machine readable media on which are stored (1) the layout parameters of the, present invention and/or (2) program instructions for using the present invention in performing operations on a computer. Such media includes by way of example magnetic tape, magnetic disks, optically readable media such as CD ROMs and semiconductor memory such as PCMCIA cards. The medium may also take the form of a portable item such as a small disk, diskette or cassette. The medium may also take the form of a larger or immobile item such as a hard disk drive or a computer RAM. 
     According to the present invention, a client in a client-server system monitors server performance. One counter maintains the number of requests made to the server. Another counter maintains the number of replies received from the server. These counters are increased whenever a request is sent to the server or whenever the client receives a reply. The server performance is determined by comparing a reply-request ratio with a predefined minimum ratio. The reply-request ratio is the number of replies received from the server, divided by the number of requests sent to the server. If the reply-request ratio is less than the minimum ratio, an indication that server performance is less than expected is made. The client may use this information to determine what, if any, corrective actions should be taken. The corrective actions may include switching over to a secondary or backup server. 
     Turning now to FIG. 2, a block diagram that illustrates a computer network according to one embodiment of the present invention is illustrated. The computer network  30  comprises a bus  32 , at least one client  34  and at least one server  36 . In operation, client  34  sends a request message  38  from client  34  to server  36 . Server  36  receives the request message  38  and sends a reply message  40  from server  36  to client  34 . A performance monitor  42  maintains a count of the number of request messages sent to server  36  and a count of the number of reply messages received from server  36 . When the ratio of replies to requests falls below a predetermined threshold, an indication that the server  36  performance is less than expected is made. When an indication that server  36  performance is less than expected is made, corrective measures may be implemented. For example, a backup server may be brought online. 
     The illustration of a client-server system having only one server and one client is not intended to be limiting in any way. Those of ordinary skill in the art will recognize that the invention may be applied to client-server systems including multiple clients and servers. Furthermore, the invention may be used in client-server systems in which a single client communicates with multiple servers. 
     Turning now to FIG. 3A, a state diagram that illustrates a method for determining the performance of a server in accordance with one embodiment of the present invention is presented. In state  44 , send requests and the receipt of replies are monitored. When a reply is received, a reply count is incremented in state  45 . When a send request is pending, a request count is incremented in state  46 . After a minimum time has elapsed, the system transitions to state  47  and a reply-request ratio is calculated by dividing the reply count by the request count. If the ratio is less than or equal to a minimum ratio, the variable “Server_Down” is set to “True” in state  48 , indicating that the server  36  performance is less than expected. If the ratio is greater than the minimum ratio, the variable “Server_Down” is set to “False” in state  49 , indicating that the server  36  performance is acceptable. After setting the “Server_Down” variable in states  48  and  49 , the request count and the reply count are reset to their initial values and the system moves back to state  44  and monitors replies and requests. 
     According to one embodiment of the present invention, separate tasks are employed to perform the activities represented by states  44 - 46  and states  47 - 49 , thus allowing the monitoring activities and the reply-request ratio calculation to proceed in parallel. 
     Turning now to FIG. 3B, a flow diagram that illustrates a method for determining the performance of a server in accordance with one embodiment of the present invention is presented. At reference numeral  50 , a determination is made regarding whether a send request is pending. If a send request is pending, a request count is incremented at reference numeral  52 . At reference numeral  54 , a determination is made regarding whether a reply from server  36  has been received. If a reply has been received, a reply count is incremented at reference numeral  56 . 
     At reference numeral  58 , a determination is made regarding whether the amount of time elapsed since the last reply-request ratio calculation is less than or equal to a minimum time. If not enough time has elapsed, execution continues at reference numeral  50 . If enough time has elapsed since the last reply-request ratio calculation, a reply-request ratio is calculated by dividing the reply count by the request count at reference numeral  60 . At reference numeral  62 , a determination is made regarding whether the reply-request ratio is less than or equal to a minimum reply-request ratio. If the ratio greater than the minimum reply-request ratio, the variable “Server_Down” is set to “False” at reference numeral  64 , indicating that the server  36  performance is acceptable. If the ratio is less than or equal to the minimum reply-request ratio, the variable “Server_Down” is set to “True” at reference numeral  66 , indicating that server  36  performance is less than expected. At reference numeral  68 , the reply count and request count are reset to their initial values. 
     According to one embodiment of the present invention, the server status is determined when the client is about to send a request to the server. This is illustrated in FIG.  4 . Turning now to FIG. 4, a flow diagram that illustrates one embodiment of the present invention is presented. At reference numeral  70 , a determination is made regarding whether a send request is pending. If a send request is pending, a request count is incremented at reference numeral  72 . At reference numeral  74 , a determination regarding whether server  36  performance is less than expected is made. At reference numeral  76 , the send request is processed. If a send request is not pending, a determination is made regarding whether a reply from server  36  has been received at. reference numeral  78 . If a reply has been received, a reply count is incremented at reference numeral  80  and the reply message is processed at reference numeral  82 . 
     According to one embodiment of the present invention, the reply-request ratio is calculated only when the request count has exceeded a minimum number of requests. Varying the minimum number of requests may modify the accuracy of the reply-request ratio. A relatively large minimum number of requests will increase the sample size and thus provide a relatively accurate reply-request ratio. 
     Turning now to FIG. 5, a flow diagram that illustrates determining the server status in accordance with one embodiment of the present invention is presented. At reference numeral  90 , a determination is made regarding whether the request count is less than a minimum number of requests. If the request count is greater than or equal to the minimum number of requests, a reply-request ratio is calculated by dividing the reply count by the request count at reference numeral  92 . At reference numeral  94 , a determination is made regarding whether the reply-request ratio is less than or equal to a minimum reply-request ratio. If the ratio is greater than the minimum reply-request ratio, the variable “Server_Down” is set to “False” at reference numeral  96 , indicating that server  36  performance is acceptable. If the ratio is less than or equal to the minimum reply-request ratio, the variable “Server_Down” is set to “True” at reference numeral  98 , indicating that server  36  performance is less than expected. At reference numeral  100 , the reply count and request count are reset to their initial values in preparation for the next reply-request ratio calculation. 
     According to one embodiment of the present invention, the reply-request ratio is calculated only when a predetermined amount of time has elapsed since the last time the reply-request ratio was calculated. Varying the predetermined amount of time may modify the accuracy of the reply-request ratio. A relatively large predetermined amount of time will provide a relatively accurate reply-request ratio. 
     Turning now to FIG. 6, a flow diagram that illustrates determining the server status in accordance with one embodiment of the present invention is presented. At reference numeral  112 , a determination is made regarding whether a predetermined time has elapsed. If the predetermined time has elapsed, a reply-request ratio is calculated by dividing the reply count by the request count at reference numeral  114 . At reference numeral  116 , a determination is made regarding whether the reply-request ratio is less than or equal to a minimum reply-request ratio. If the ratio is greater than the minimum reply-request ratio, the variable “Server_Down” is set to “False” at reference numeral  117 , indicating that server  36  performance is acceptable. If the ratio is less than or equal to the minimum reply-request ratio, the variable “Server_Down” is set to “True” at reference numeral  118 , indicating that server  36  performance is less than expected. At reference numeral  120 , the reply count and request count are reset to their initial values. 
     Requests are typically sent at random intervals and replies are received at random intervals. It is therefore possible that the reply-request ratio is calculated at a point immediately after several requests are sent out in a short period, but before most of the replies are received, as illustrated in FIG.  7 . 
     Turning now to FIG. 7, a block diagram that illustrates the timing relationship of send and receive messages is presented. In time period  130 , requests  132  and  134  are sent to the server and replies  136  and  138  are received from the server, making the reply-request ratio equal to the value one. In time period  140 , requests  142 ,  144  and  146  are sent to the server  36  and reply  148  is received from the server  36  immediately before the reply-request ratio is calculated at reference numeral  150 . In this case, the reply-request ratio is 1/3 (one reply for every three requests). 
     In time period  152 , replies  154  and  156  are received and requests  158  and  160  are sent, making the reply-request ratio equal to the value one. Thus, basing the server  36  status on a reply-request ratio calculated at reference numeral  150  could lead to a false indication of a poorly performing server and could thus unnecessarily trigger corrective action. According to one embodiment of the present invention, an indication that server  36  performance is less than expected is made only after the reply-request ratio is less than or equal to a minimum reply-request ratio for a predetermined number of consecutive reply-request ratio calculations. According to a preferred embodiment of the present invention, the predetermined number of consecutive reply-request ratio calculations is two. 
     Turning now to FIG. 8, a flow diagram that illustrates determining the server status in accordance with one embodiment of the present invention is presented. At reference numeral  172 , a determination is made regarding whether a predetermined time has elapsed. At reference numeral  174 , a determination is made regarding whether the request count is less than a minimum number of requests. If the predetermined time has elapsed and if the request count is greater than or equal to a minimum request count, a reply-request ratio is calculated at reference numeral  176 . At reference numeral  178 , a determination is made regarding whether the reply-request ratio is less than or equal to a minimum reply-request ratio. If the ratio is greater than the minimum reply-request ratio, a variable “Going_Down” is set to “False” at reference numeral  180 , indicating that the server reply-request ratio should not be checked again in a second consecutive period. 
     If the reply-request ratio of the current period is less than or equal to the minimum ratio, the value of the variable “Going_Down” is checked at reference numeral  182 . 
     The variable “Going_Down” indicates whether the reply-request ratio of the previous period is less than or equal to the minimum ratio. If “Going_Down” is “True”, the variable “Server_Down” is set to “True” at reference numeral  186 , indicating that the server  36  performance is less than expected. At reference numeral  188 , the variable “Going_Down” is set to “False”, indicating that the server  36  performance should not be checked again in a second consecutive period. If the value of the variable “Going_Down” is “False” at reference numeral  182 , the variable “Going_Down” is set to “True” at reference numeral  184 , indicating that the server  36  performance should be checked again in a second consecutive period. 
     If the reply-request ratio of the current period is greater than the minimum ratio at reference numeral  178 , or if the reply-request ratio of the previous period is greater than the minimum ratio at reference numeral  182 , the variable “Server_Down” is set to “False” at reference numeral  185 , indicating that the server  36  performance is acceptable. At reference numeral  190 , the reply count and request count are reset to their initial values in preparation for the next reply-request ratio calculation 
     The above embodiment thus extends the amount of time required to detect a poorly performing server  36 . However, false detections are made less likely because the replies that were excluded from an earlier reply-request calculation are more likely to be received before the final reply-request ratio calculation, thus resulting in a final reply-request ratio that is greater than the minimum ratio. 
     In the embodiments described herein, the use of counters that are incremented in the positive direction by a particular number until a criterion is met is not intended to be limiting in any way. Those of ordinary skill in the art will recognize that many counting schemes are applicable as well. For example, counters that are decremented in the negative direction by a number until a criterion is met could be employed. 
     According to a presently preferred embodiment, the present invention may be implemented in software or firmware, as well as in programmable gate array devices, Application Specific Integrated Circuits (ASICs), and other hardware. 
     While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclosure that many more modifications than mentioned above are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the appended claims.