Patent Application
20200327004
In modern computer technology, server computer systems may be used to provide functionality or services for other client computer systems. The server computer system may host data and/or applications such as a website. The client computer system may be able to access and manipulate the data hosted by the server computer system. For example, the server computer system may host a website that is managed by a user and accessed by third party user. The user managing the website may wish to monitor the performance of the website.
A computer system, such as a server computer system, can execute applications to host a service or functionality for client computer systems. For example, a server can host a website. In one example, the server can host a service that has a Hypertext Transfer Protocol (HTTP) transaction with HTTP parameters. The server can monitor the performance of the HTTP transaction via an agent installed on the server. The agent can determine that there may be a performance issue, based on performance metrics, for the HTTP transaction. A user responsible for managing the service provided by the server may wish to investigate the root cause of the performance issue so that the root cause can be remedied. In this context or others, a user may experience difficulties tracing the root cause of the performance issue due to too much data related to the values for the performance metrics. Examples of the present disclosure provide technology for discovering a probable root cause of a performance issue. In the present disclosure, the “probable root cause” may be defined to be a suggestion to a user as to what may be causing the performance issue. The user may then take the suggestion to investigate further into the performance issue of the transaction. In some examples, the present disclosure divides a set of calls or instances for the HTTP transaction into multiple groups, e.g., two groups. The groups may be labeled as a first group or as a second group, where the first group has the call with performance issues and the second group has the remainder of the calls or calls with an acceptable level of performance or calls without performance issues. The first group of calls may be searched to discover a common subset of parameters. The second group may then be searched for the same common subset of parameters. If the second group does not have the common subset of parameters then the common subset of parameters may be determined to be a probable root cause of the performance issue and the user may be notified. If the second group does have the common subset of parameters, then the common subset of parameters may not be the probable root cause and further steps may be taken to determine the probable root cause.
A “parameter,” including a common subset of parameters, can be defined to include a parameter of an HTTP transaction and may be user defined. To illustrate by example, the parameter may be a request parameter and the individual calls in the set of calls for an HTTP transaction may have a plurality of parameters including different combinations of parameters. For example, a parameter for an HTTP transaction may be a “category” or a “query,” and a combination of parameters may be related thereto, e.g., “category, sort” or “query, color” or “query, language” etc. In one example, HTTP header fields can be components of the header section of request and response messages in the HTTP and define the operating parameters of an HTTP transaction.
A further step can include searching and discovering that the first group has a common attribute value. If the second group does not contain the common attribute value, then the common attribute value may be determined to be the probable root cause of the performance issue and the user may be notified. If the common attribute value is found in the second group, then the common attribute value may not be the probable root cause. It is noted that an “attribute” for a call, including a common attribute value, may refer to a specific value and is different than a more general parameter for an HTTP transaction. For example, the common attribute value may include a value for a long name, a long word value, a long value, a date value, a range value, a number value, a color value, a Boolean value, and/or a language value. To illustrate by example, calls in the first group with performance issues may contain properties or a common attribute with a specific value, e.g., value expressed in Japanese. If the second group without performance issues does not have common attributes with the specific value, e.g., the specific language at issue such as Japanese, then the probable root cause of the performance issue may be the common attribute with values related to that specific language. A user may then be notified that the probable root cause may be in how the HTTP transaction is dealing with the common attributes with values in the specific language. Likewise, as mentioned, other more specific attributes may be the cause of the performance issue other than language, e.g. Japanese in the above example. As mentioned, the performance issue may be caused by number value or range of number values, a long word or long name value, a date or date range value, a Boolean word grouping value, a specific color value, e.g., blue, etc.
One example of an environment for discovering the probable root cause of a performance issue is shown in
In one example, a user of the user device 108 may be responsible for monitoring the performance of service 105 such that service 105 runs smoothly and may be able to be used by third party users and devices such the third party user 112. The agent 104 may serve to notify user device 108 when a problem occurs such as a performance issue so that the user may investigate and ultimately remedy the root cause of the performance issue. The agent 104 can provide tools to show the user of user device 108 performance metrics that can be calculated over server 102 and network 106. However, the user may need additional assistance for investigation into the probable root cause. For example, the agent 104 may display all the performance metrics by grouping them by the HTTP Request's uniform resource locator (URL). In so doing, there may be no difference on a user interface (UI) between the transaction's calls except its timestamp and the performance metrics. If the problem of the transaction happened only when some of the URL parameters have specific values, or when specific parameters exist on the URL, it will be difficult to the user to discover the root cause.
Additionally, in one scenario, a URL may not define only one transaction because the server 102 calls different service for every parameter's value. In an example where the URL calls the same service, the URL can define the transaction. In such an example, the user may want to consider it as one transaction for all the performance monitors without breaking the transaction to many transactions. Moreover, the agent 104 may allow the user to configure the agent 104 to send the URL's parameters. Then, the HTTP parameters of calls will be displayed. In this example, the user may receive too much data that creates difficulty to find which parameter(s) may be the root cause.
The present disclosure overcomes these issues by providing the agent 104 with PRC determiner 106 which may automatically discover a probable root cause of a performance issue which may be sent to the user device 108 and displayed in the interface 110. In other words, the present disclosure describes systems and techniques for automatically help the user understand a probable root cause without the user having to sort through the vast amount of data related to a performance issue. The steps that PRC determiner 106 may use to determine the probable root cause are depicted and described in reference to
Method 200 may be described a method, process, or flow for discovering a probable root cause of a performance issue. This may also be referred to as determining a hypothesis of a root cause for a performance issue. The probable root cause or the hypothesis may be sent to user responsible for the functionality of service to further investigate and ultimately remedy the performance issue.
The method can include processing 202, using a processor, a set of calls for a Hypertext Transfer Protocol (HTTP) transaction wherein individual calls of the set of calls have a set of parameters. For example, the processor may refer to a processor of server 102 of
Identifying 204, using the processor, that the HTTP transaction has a performance issue that falls below a predetermined level of a performance metric. For example, the predetermined level of the performance metric may be based on speed or response time of the calls. In one example, the two millisecond time may be determined to be an average or good response time for a transaction while the 10 millisecond time considered slow. Therefore, the predetermined level of the performance metric would be set at 10 milliseconds such that every call that took 10 milliseconds or longer would be determined to have a performance issue. This may be monitored by the agent 104. In one example, the agent 104 monitors all calls and automatically determines an average call time and sets the predetermined level for the performance metric of time.
Another step can include separating 206, using the processor, the set of calls into a first group with the performance issue and a second group without the performance issue. In one example, the first group may be referred to as the bad group and the second group may be referred to as the good group (or negative and positive, or any other label differentiating less desired groups compared to desired groups). These relative terms, such as “good/bad” or “positive/negative,” are used only for convenience to describe that the first group includes may be a problematic group and the second group can be a group without a problematic performance issue. The second group may include the remainder of the calls or the calls with an acceptable level of performance meaning that the calls of the second group may not be without any performance issue, but may not have the same performance issue as the calls in the first group.
At 208, discovering, using the processor, a common subset of parameters among the first group. In one example, the discovering automatically traces the set of calls for the HTTP transaction across multiple frontend and backend application servers.
Another step can include determining 210 that a common subset of parameters may be a probable root cause of the performance issue if the common subset of parameters is not found in the second group.
An additional step can include notifying a user of the probable root cause. The user may be notified via interface 110 using the user device 108. In one example, the method 200 may be executed more than once to provide more than one probable root cause based on the common subset of parameters to the user.
If the common subset of parameters is found in the second group, then the common subset of parameters may not be determined to be the probable root cause and further investigation is required. The further investigation may be the additional step of searching for a common attribute value among the first group if the common subset of parameters is found in the second group; and determining that the common attribute value is a probable root cause of the performance issue if the common attribute value is not found in the second group. The common attribute value may be a long name value, a long word value, a long value, a date value, a range value, a number value, a Boolean value, a color value, or a language value, for example. Other common attribute values other than these can also be used in accordance with examples of the present disclosure.
Method 300 may be described a method, process, or flow for discovering a probable root cause of a performance issue. This may also be referred to as determining a hypothesis of a root cause for a performance issue. The probable root cause or the hypothesis may be sent to user responsible for the functionality of service to further investigate and ultimately remedy the performance issue.
The method can include processing 302 a set of calls for a Hypertext Transfer Protocol (HTTP) transaction. For example, the processor may refer to a processor of server 102 of
The method can include identifying 304 that the HTTP transaction has a performance issue that falls below a predetermined level of a performance metric. The method can further include separating 306 the set of calls into a first group with the performance issue and a second group without the performance issue.
The method can further include discovering 308 a common attribute value among the first group. The common attribute value may a long name value, a long word value, a long value, a date value, a range value, a number value, a Boolean value, a color value, or a language value, for example. The step of discovering 308 may be repeated a plurality of times when searching for a different common attribute value until a common attribute value is found.
The method can further include determining 310 that the common attribute value is a probable root cause of the performance issue if the common attribute value is not found in the second group.
In one example, for the attributes, the method may include checking if there is property that answers to that attribute in every call in the first group. For example, for attribute long name, the method may include checking that in every call there may be a property that has a long name. The definition of long name is that the name's length bigger than predefined threshold. Then, if one of the calls with a long name is not found, the method may include moving on to the next attribute which may be a long word value or a long value, for example. Again, the method can be used to check if all the calls have property with value that its length bigger than predefined threshold, and so on. For attribute date, the method may include checking if all calls have a property that may have a value represented date. For attribute range, the method may include checking if there is a property in every call that represents a range of dates. For attribute number, the method can include checking if there is a property in every call that its value is a number.
In one example, the method 300 may find that a number may be a common attribute value for the first group. Then, the method can include checking if there a call in the second group that may have a property with the numerical value. If so, the method may include recognizing if there may be a difference between the numerical properties from the first group and the numerical properties from the second group. For example, in one group the number type may be integer while in the other group may be float. Or, in one of the groups the numbers may be considerably bigger from the other group. Or, in one of the groups the numbers may be negative while in the other group they positive. If the method has lead to discovering or finding any considerable difference, it may be assumed that the attribute number is not the root cause, thus continuing to the next attribute in the collection.
An additional step can include notifying a user of the probable root cause. The user may be notified via interface 110 using the user device 108. In one example, the method can be carried out or executed more than once to provide more than one probable root cause based on the common attribute value to the user. The user may also be provided with a probable root cause based on a common subset of parameters as well as a probable root cause based on a common attribute value.
Additional steps may precede 308 including the steps of discovering a common subset of parameters among the first group; and determining that the common subset of parameters is a probable root cause of the performance issue if the common subset of parameters is not found in the second group.
In one example, a service can be hosted by the server at a web site, such as www.mywarehouse.com. Table 1 shows calls to the web site page in a 30 minute period and the response latency for the calls.
To apply method 400 to Table 1, the calls for Table 1 can be divided into two groups by sorting them according to response latency and then, finding the ‘jump’ in the values. In this example the ‘jump’ is between 15ms and 211ms. Table 2 shows the calls after the division:
An additional step can include finding the common subset of properties in group the first group. In this example, the subset may be “Category, Sort.” This parameter subset also appears in calls from the second group. Therefore this subset may not be the probable root cause.
A third step may include finding a common attribute property or a common attribute value. In this specific example, the common attribute may be that the property ‘Sort’ contains the value ‘yes.’ That property may also exist in calls from the second group, but it may not share the same attribute. The values of ‘sort’ in the second group may not be equal to ‘yes.’
So, method 400 can be used to notify the user that the root cause may be the property ‘sort’ whenever its value equals to ‘yes.’ There are other more specific attribute values other than ‘yes’ or ‘no,’ as this is provided by example only. For example, the attribute may be a specific color, a specific number, a number range, a word, as well as other attributes listed herein.
In a different example, the service hosted by the server may be a web site such as www.buyme.com. Table 3 shows calls to the web site page in a 30 minute period and the CPU Usage for the calls.
To apply method 400 to Table 3, steps can include dividing the calls into two groups by sorting them according to CPU Usage and then, finding the ‘jump’ in the values. In this example, the ‘jump’ may be identified to be between 26% and 72%. Table 4 shows the calls after the division.
Another step of method 400 can include finding a common subset of properties in the first group. In this example, the subset may be ‘Color.’ This subset does not appear on calls from the second group. So, the method can include notifying the user that the root cause may be the property ‘Color.’ As a note, if the subset property “Color” is not found to be the subset of parameters that identifies the probably root cause, a common attribute may be discovered in additional steps, which may be a specific color, for example.
With reference now to
System 500 of
System 500 also may include a computer usable non-volatile memory 510, e.g., read only memory (ROM), coupled to bus 504 for storing static information and instructions for processors 406A, 406B, and 406C. A data storage unit 512 (e.g., a magnetic or optical disk and disk drive) may also be present and may be coupled to bus 504 for storing information and instructions. System 500 also may include an alpha-numeric input device 514 including alphanumeric and function keys coupled to bus 504 for communicating information and command selections to processor 506A or processors 506A, 506B, and 506C. System 500 also may include a cursor control device 516 coupled to bus 504 for communicating user input information and command selections to processor 506A or processors 506A, 506B, and 506C. System 500 of the present example also can include a display device 518 coupled to bus 504 for displaying information.
Referring still to
System 500 can also include a cursor directed by other methods such as, for example, voice commands. System 500 also may include an I/O device 520 for coupling system 500 with external entities. For example, in one example, I/O device 520 can include a modem for enabling wired or wireless communications between system 500 and an external network such as, but not limited to, the Internet. A more detailed discussion of the present disclosure is found below.
Referring still to
System 500 also may include signal generating and receiving device(s) 530 coupled with bus 504 for enabling system 500 to interface with other electronic devices and computer systems. Signal generating and receiving device(s) 530 of the present example may include wired serial adaptors, modems, and network adaptors, wireless modems, and wireless network adaptors, and other such communication disclosure. The signal generating and receiving device(s) 530 may work in conjunction with communication interface(s) 532 for coupling information to and/or from system 500. Communication interface 532 may include a serial port, parallel port, Universal Serial Bus (USB), Ethernet port, antenna, or other input/output interface. Communication interface 532 may physically, electrically, optically, or wirelessly (e.g. via radio frequency) couple system 500 with another device, such as a cellular telephone, radio, or computer system.
The computing system 500 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present disclosure. Neither should the computing environment 500 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computing system 500.
The present disclosure may be described in the general context of non-transitory computer-executable instructions, such as programs, being executed by a computer. Generally, programs include applications, routines, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, programs may be located in both local and remote non-transitory computer-storage media including memory-storage devices.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US16/29035 | 4/22/2016 | WO | 00 |
