Resource scheduling method, device and network system

Abstract

Embodiments of the present application provide a resource scheduling method, apparatus and system, which can collect user experience data of a terminal device and server performance data of a server when an application is issued to be online for the first time, the user experience data including data generated during the operation of a target APP and related to server performance, and the user experience data including data generated during the operation of the target APP and related to the server performance. The server performance data comprises resource use data and / or interface performance data of the server; and then comprehensively judging whether the server side has insufficient performance or not according to the user experience data and the server side performance data, and accurately determining the number of instance nodes needing to be added according to the performance reference data when the server side has the insufficient performance. Therefore, according to the technical scheme of the embodiment of the invention, the server side can be expanded timely and accurately, the insufficient performance state of the server side is eliminated, downtime of the server side is avoided, and the user experience is improved when the application program is launched at the first time to be online.

Description

[0001] This application is a divisional application. The application number of the original application is 202010469738.8, and the original application date is May 28, 2020. The entire contents of the original application are incorporated into this application by reference. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a resource scheduling method, device and network system. Background Art

[0003] Various terminal devices such as mobile phones, tablet computers, and personal computers (PCs) can install various application APPs. Terminal devices with application programs installed can establish a network connection with the server provided by the operator of the application program to interact with data and realize various application functions.

[0004] Data interaction between terminal devices and servers will generate data traffic. Generally speaking, the larger the user scale of an application, the more terminal devices are online at the same time, the greater the data traffic the server bears, and the higher the server resource occupancy rate. Therefore, in order to ensure the smooth operation of the server, operation and maintenance personnel usually configure server resources accordingly based on the user scale. However, when an application is first released, operation and maintenance personnel usually lack user scale data, so they cannot accurately predict the traffic after the application is first launched, and thus cannot determine the scale of the server to be invested.

[0005] In this case, if fewer server resources are invested and the data traffic after the application is first launched is very large, the server will experience insufficient performance or even crash due to the huge traffic impact, causing the application to run slowly, be unable to connect to the server, be unable to log in, and have high latency (ping value), etc., seriously affecting the user experience, reducing the user experience of the first-released application, and causing user loss. Summary of the invention

[0006] The embodiments of the present application provide a resource scheduling method, device and network system, which can timely and accurately schedule server resources for an application when the application is first launched online, so as to avoid insufficient performance or downtime on the server side and improve the user experience when the application is first launched online.

[0007] In the first aspect, the embodiment of the present application provides a resource scheduling method. The method includes: obtaining user experience data of the target application APP from a terminal device installed with the target APP, and obtaining server performance data from the server of the target APP, wherein the user experience data includes data related to the server performance generated during the operation of the target APP, and the server performance data includes resource usage data and / or interface performance data of the server; judging whether the server has insufficient performance according to the user experience data and the server performance data; when the server performance is insufficient, determining the number of instance nodes that the server needs to increase according to the number of terminal devices currently online and the preset performance benchmark data, the performance benchmark data includes the number of terminal devices supported by each instance node; increasing the instance nodes of the server according to the number of instance nodes that the server needs to increase.

[0008] In this way, when the application is first launched, the resource scheduling method of the embodiment of the present application can collect the user experience data of the terminal device and the server performance data of the server, and then comprehensively judge whether the server has performance deficiencies based on the user experience data and the server performance data. When the server has performance deficiencies, the number of instance nodes that need to be added is accurately determined based on the performance benchmark data, thereby achieving timely and accurate capacity expansion of the server, eliminating the performance deficiencies of the server, avoiding server downtime, and improving the user experience when the application is first launched.

[0009] In an optional implementation, the user experience data is collected by a data collection software development kit SDK installed on the terminal device.

[0010] In an optional implementation, the data collection SDK obtains the user experience data reported by the target APP through its own user experience data reporting application program interface API.

[0011] In an optional implementation, the target APP is used to store the generated user experience data in a first log file, and the data collection SDK collects the user experience data by monitoring the first log file or the directory where the first log file is located.

[0012] In an optional implementation, the server-side performance data is collected by a data collection software agent installed on the server.

[0013] In an optional implementation, the data collection agent obtains the server performance data reported by the server through its own performance data reporting API.

[0014] In an optional implementation, the server is used to store the generated server performance data in a second log file, and the data collection agent is used to monitor the second log file or the directory where the second log file is located to collect the server performance data.

[0015] In an optional implementation, whether the server has insufficient performance is determined based on user experience data and server performance data, including: matching one or more indicator values ​​in the user experience data and / or server performance data with their corresponding thresholds, and determining whether the server has insufficient performance based on the matching results.

[0016] In an optional implementation, when at least one indicator value in the user experience data and / or the server performance data exceeds a range defined by its corresponding threshold value, the server performance is insufficient.

[0017] In an optional implementation, when the product of the number of instance nodes on the server minus 1 and the performance benchmark data is greater than the number of terminal devices currently online, the server has excess performance.

[0018] In an optional implementation, the user experience data and / or server performance data include one or more delay class indicator values ​​and one or more resource occupancy class indicator values, each delay class indicator value corresponds to a delay class threshold, and each resource occupancy class indicator value corresponds to a resource occupancy class threshold.

[0019] In an optional implementation, the number of instance nodes that need to be added to the server is determined based on the number of terminal devices currently online and preset performance benchmark data, including: dividing the number of terminal devices currently online by the performance benchmark data, and then subtracting the number of instance nodes on the server to obtain the predicted number of server instance nodes that need to be adjusted; when the predicted number of server instance nodes that need to be adjusted is greater than or equal to 1, rounding the predicted number of server instance nodes that need to be adjusted as the number of instance nodes that need to be added to the server.

[0020] In an optional implementation, the method further includes: when the predicted number of server instance nodes that need to be adjusted is less than or equal to -1, rounding the absolute value of the predicted number of server instance nodes that need to be adjusted as the number of server instance nodes that need to be reduced.

[0021] In an optional implementation, the method also includes: multiplying the number of instance nodes on the server by the performance benchmark data to obtain the number of terminal devices theoretically supported by the server; if the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server and the server has insufficient performance, reducing the value of the performance benchmark data.

[0022] In an optional implementation, reducing the value of the performance benchmark data includes: periodically reducing the value of the performance benchmark data, the value of the performance benchmark data after each reduction is equal to the value of the performance benchmark data before the reduction multiplied by an empirical coefficient, and the empirical coefficient is greater than 0 and less than 1.

[0023] In an optional implementation, the method also includes: when the server is released from the insufficient performance state, the number of terminal devices that the server's current number of instance nodes can support is saved in a policy warehouse, and the policy warehouse includes the number of terminal devices that the server can support under different numbers of instance nodes.

[0024] In an optional implementation, the method further includes: when the performance of the server is insufficient, determining the number of instance nodes to be added from the policy repository according to the number of terminal devices currently online.

[0025] In a second aspect, an embodiment of the present application also provides a resource scheduling device, which includes: a transceiver, a memory and a processor; wherein the memory includes program instructions, and when the program instructions are executed by the processor, the device is used to perform the following steps: obtaining user experience data of a target application APP from a terminal device on which the target application APP is installed, and obtaining server performance data from the server of the target APP, wherein the user experience data includes data related to server performance generated during the operation of the target APP, and the server performance data includes resource usage data and / or interface performance data of the server; judging whether the server has insufficient performance based on the user experience data and the server performance data; when the server performance is insufficient, determining the number of instance nodes that the server needs to add based on the number of terminal devices currently online and preset performance benchmark data, the performance benchmark data includes the number of terminal devices supported by each instance node; increasing the instance nodes of the server based on the number of instance nodes that the server needs to add.

[0026] Furthermore, the device provided in the embodiments of the present application can also execute other implementations of the aforementioned first aspect.

[0027] In a third aspect, an embodiment of the present application further provides a network system, which includes: a server of a target APP, a terminal device on which the target APP is installed, and a resource scheduling device; wherein the terminal device is used to send user experience data of the target APP to the resource scheduling device, and the user experience data includes data related to server performance generated during the operation of the target APP; the server is used to send server performance data to the resource scheduling device, and the server performance data includes resource usage data and / or interface performance data of the server; the resource scheduling device is used to determine whether the server has insufficient performance based on the user experience data and the server performance data; the resource scheduling device is also used to determine the number of instance nodes that the server needs to add when the server performance is insufficient based on the number of terminal devices currently online and preset performance benchmark data, and the performance benchmark data includes the number of terminal devices supported by each instance node; the resource scheduling device is also used to increase the instance nodes of the server according to the number of instance nodes that the server needs to increase.

[0028] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored, and when the computer-readable storage medium is run on a computer, the computer executes the methods in the above aspects.

[0029] In a fifth aspect, an embodiment of the present application further provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the above-mentioned methods.

[0030] In a sixth aspect, an embodiment of the present application further provides a chip system, which includes a processor for supporting the above-mentioned device or system to implement the functions involved in the above-mentioned aspects, for example, generating or processing the information involved in the above-mentioned method. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a schematic diagram of the network connection between the server and the terminal device;

[0032] Figure 2 It is a graph of the number of application users and the data traffic on the server side;

[0033] Figure 3 It is a schematic diagram of some scenarios that affect the user experience;

[0034] Figure 4 A schematic diagram of how to scale up and down the server when the application is first launched.

[0035] Figure 5 Another diagram of scaling up and down the server when the application is first launched.

[0036] Figure 6is a schematic diagram of a device for implementing a resource scheduling method provided in an embodiment of the present application;

[0037] Figure 7 It is a deployment diagram of a device for implementing a resource scheduling method provided in an embodiment of the present application;

[0038] Figure 8 is a flow chart of a resource scheduling method provided in an embodiment of the present application;

[0039] Fig. 9 This is a schematic diagram of a terminal device reporting user experience data provided by an embodiment of the present application;

[0040] Fig.10 This is a schematic diagram of a server reporting server performance data provided by an embodiment of the present application;

[0041] Fig.11 is a structural schematic diagram of a health model shown in an embodiment of the present application;

[0042] Fig.12 It is a schematic diagram of an application scenario corresponding to when the performance benchmark database includes multiple performance benchmark data;

[0043] Fig.13 is a flow chart of correcting performance benchmark data provided by an embodiment of the present application;

[0044] Fig.14 It is a flow chart of a method for implementing resource scheduling with the help of a policy warehouse provided in an embodiment of the present application;

[0045] Fig.15 It is a structural diagram of a resource scheduling device provided in an embodiment of the present application;

[0046] Fig.16 It is a structural diagram of a network system provided by an embodiment of the present application;

[0047] Fig.17 It is a structural schematic diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this embodiment, unless otherwise specified, "plurality" means two or more.

[0049] Various terminal devices such as mobile phones, tablet computers, and personal computers (PCs) can install various applications APPs. Terminal devices with applications installed can establish a network connection with the server provided by the operator of the application, and obtain the resources and information required for the operation of the application through data interaction with the server.

[0050] Figure 1 This is a schematic diagram of the network connection between the server and the terminal device. Figure 1 As shown, the user can download the application from the application market program 13 built into the terminal device 11, the download link provided by the application operator, and a third-party application market or download link and other optional channels and install it in the terminal device 11. An application will be installed by many users in the terminal device 11 they use, and these users may use this application at the same time, so the server 12 will establish a network connection with multiple terminal devices 11 at the same time. Among them, the server 12 can be a server or server cluster (multiple servers) provided by the operator of the application, or it can be a cloud server provided by a cloud server operator (for example: Huawei Cloud, Alibaba Cloud, Tencent Cloud, Microsoft Azure, etc.) for the operator of the application. This embodiment of the application does not specifically limit this. The terminal device 11 may include, for example, a mobile phone, a tablet computer, a personal computer, a workstation device, a large-screen device (for example: smart screen, smart TV, etc.), a handheld game console, a home game console, a virtual reality device, an augmented reality device, a mixed reality device, etc. This embodiment of the application does not specifically limit this. Devices that can install applications and establish connections with the server 12 belong to the terminal device 11 of the embodiment of the application. It is understandable that the link between the server 12 and the terminal device 11 usually includes node devices such as switches, routers, and load balancers. Figure 1 In order to facilitate the description of the connection relationship between the server 12 and the terminal device 11, these nodes are not shown.

[0051] The application programs in the embodiments of the present application may include game applications and non-game applications, wherein the non-game applications include but are not limited to: media applications (such as short video applications, music applications, live broadcast applications, audio and video applications, etc.), social applications (such as instant messaging applications, social network applications, microblogging applications, etc.), shopping applications, ticketing applications, financial management applications, life service applications (such as taxi applications, map applications, food delivery applications), etc.

[0052] Taking a game application as an example, when a user opens a game application on a terminal device 11, the terminal device 11 will establish a network connection with its server 12 to obtain resources (such as map resources, character resources, UI resources, etc.) required for the game application to run from the server 12, and process the user's input during the game application. It can be seen that during the operation of the application, data traffic will be generated between the terminal device 11 and the server 12 of the application.

[0053] Generally speaking, the data traffic borne by the server of an application is related to the number of online users of the application (that is, the number of users who use the application at the same time). Figure 2 As shown, generally, the more users use the application at the same time, the more terminal devices are connected to the server, and the greater the data traffic the server bears; the fewer users use the application at the same time, the fewer terminal devices are connected to the server, and the smaller the data traffic the server bears. In addition, the server needs to occupy certain server resources when sending, receiving and processing data traffic, such as processor resources, memory resources (such as RAM resources) and I / O resources. Generally speaking, the greater the data traffic, the higher the occupancy rate of the server resources, and the smaller the data traffic, the lower the occupancy rate of the server resources.

[0054] Generally speaking, since server resources are usually limited, when the data traffic on the server is far lower than its processing capacity, the server will have excess system resources. When the data traffic on the server exceeds its processing capacity, the server will have insufficient resources or even crash. To avoid the above situation, the operator of the application will count the user scale of the application, and then determine the scale of the server to be invested based on the user scale of the application, so as to avoid both excess and insufficient resources on the server, so that both the server and the application can run smoothly.

[0055] However, when an application is first released (launched), operators usually lack user scale data and cannot accurately predict the traffic after the application is first launched, so they cannot determine the scale of the server to be invested. In this case, if the server resources invested are small, and the data traffic after the application is first launched is very large, the server will crash due to the traffic impact, causing the application on the terminal device to run slowly, unable to connect to the server, unable to log in, and too high latency (ping value), which seriously affects the user experience, reduces the user's first impression of the first-launched application, and leads to user loss.

[0056] Figure 3 Some scenarios that affect the user experience are shown in Figure 3In scenario a, if the server has insufficient resources or crashes, when the user switches to a new scene in the game, the game application may not be able to obtain the game resources required to load the scene from the server, causing the game interface to freeze, resulting in a low FPS. Figure 3 In scenario b, if the server has insufficient resources or is down, when the user starts the game, the game application may remain on the startup screen due to the inability to connect to the server, and the spinning animation will continue to appear. Figure 3 In scenario c, if the server has insufficient resources or is down, after the user enters the account and password on the game login interface and clicks Login, the game application may fail to log in or queue up due to the inability to connect to the server, and the user cannot log in to the game normally. Figure 3 In scenario d, if the server resources are insufficient or down, the data transmission between the game application and the server will not be smooth, which will cause high latency, large delay fluctuations, packet loss and other phenomena during the game operation, affecting the user experience.

[0057] It should be noted that the "first release of an application" in the embodiment of the present application may include the release of the first version of an application that has never been released, and the release of a new version of an application that has been released. The "release" in the embodiment of the present application may include at least two forms; one form is that the application is put on the application market, such as the Play Store provided by Google, the App Gallery provided by Huawei, the Galaxy Apps store provided by Samsung, etc. This form may occur, for example, in electronic devices running Android operating system, iOS operating system, iPad OS operating system, Mac OS operating system, Harmony OS (Hongmeng) operating system, window mobile operating system and other operating systems. The above operating systems generally include an application market, and users mainly obtain applications from the application market; another form is that the operator provides a download link for the application on the Internet, so that the user can download the application to the terminal device locally and install it through the download link. This form may occur, for example, in the windows operating system or any of the above operating systems.

[0058] like Figure 4As shown, in order to improve the user experience when the application is first released, some operators currently publish the application reservation page in the application market of the terminal device or a specific webpage before the application is first released, and invite potential users who are willing to experience the application to participate in the reservation. In this way, according to the scale of users who have made reservations, the operator's operation and maintenance personnel can evaluate the data traffic scale after the application is first launched online, and prepare the corresponding server resources. After the application is first launched online, the operator's operation and maintenance personnel can use the operation and maintenance system to view the operation and maintenance indicator data and public opinion information of the application, and judge whether the server needs to be expanded based on the operation and maintenance indicator data and public opinion information. If the operation and maintenance indicator data and public opinion information show that the application has run stuck and other situations that affect the user experience, the server needs to be expanded. At this time, the operation and maintenance personnel can prepare the corresponding server hardware resources, deploy software, start the operating system, and add the new server to the production environment. After the expansion is completed, the operation and maintenance personnel can continue to monitor the operation and maintenance indicator data and public opinion information of the application to judge the expansion effect. If the expansion effect does not meet expectations, continue to expand. Among them, public opinion information may include, for example, chat content posted by users in the public chat system within the application, evaluation content and rating content of the application by users in the application market, and discussion content of the application by users in major forums, communities, and forums, etc. However, since the above method is based on the manual operation of the operation and maintenance personnel to expand the server, and the operation steps are cumbersome, the efficiency is low; and the manual operation depends on the experience of the operation and maintenance personnel, and the expansion effect is difficult to guarantee; in addition, since the first release of the application often brings an instantaneous traffic peak, if the operation and maintenance personnel cannot judge that the server needs to be expanded and complete the expansion operation in a short time, the server is likely to be overwhelmed by the instantaneous traffic, causing serious losses.

[0059] In order to overcome the shortcomings of manual expansion methods, such as Figure 5 As shown in the figure, some operators using cloud servers can also use the elastic scaling service of cloud server providers to collect resource indicators such as CPU, memory and network I / O of the server, and trigger elastic scaling policies based on these indicators and their corresponding elastic thresholds, so as to achieve the expansion and contraction of cloud servers. However, the CPU, memory and network I / O indicators of the server monitored by the elastic scaling service cannot fully reflect the status of the server. For example, when the service architecture of the server is not designed reasonably, even if the server resource occupancy is not high, the server may have reached its maximum processing capacity. In addition, since the link from the terminal device to the server also includes node devices such as routers, switches, and load balancers, the server resource indicators cannot accurately reflect the real user experience of the application on the terminal device.

[0060] In order to allocate server resources to an application in a timely and accurate manner when the application is first launched online to avoid server downtime or resource waste, an embodiment of the present application provides a resource scheduling method, which is described in detail below with reference to specific scenarios and examples. In the following description, the application corresponds to the target application in the claims.

[0061] The resource scheduling method provided in the embodiment of the present application can be based on Figure 6 The device architecture shown is implemented as Figure 6 As shown, the device includes: a data acquisition module 21, a data analysis module 22 and an execution module 23.

[0062] The data collection module 21 may include a client data collection module 211 and a server data collection module 212. The client data collection module 211 may be used to collect user experience data of the application. The user experience data may also be referred to as APP operation and maintenance indicators / data, key performance indicators (KPI) indicators, etc. The user experience data may include one or more indicator values ​​related to the server performance generated during the operation of the application, such as: the interface freeze time of the application, the application delay, the application interface call delay to the server, the interface call success rate, the number of unresponsive times of the application, etc. The server data collection module 212 may be used to collect the server performance data of the server. The server performance data may be referred to as server (device) operation and maintenance data, etc. The server performance data may include resource usage data and / or interface performance data of the server, wherein the resource usage data may include one or more indicator values ​​such as the CPU usage rate, memory usage rate and / or network I / O interface flow rate of the server, and the interface performance data may include one or more indicator values ​​such as the data throughput of the server, the server delay and / or the interface call success rate of the server to the application.

[0063] The data analysis module 22 may include a health model 221, a performance benchmark database 222, and a policy warehouse 223. The health model 221 is used to describe the running state of the application through user experience data, server performance data, and thresholds related to the user experience data and server performance data. The performance benchmark database 222 is used to store and manage performance benchmark data, wherein the performance benchmark data may include, for example, the number of terminal devices that a single instance node of the server can support. The policy warehouse 223 is used to obtain the number of server instances required for different numbers of online terminal devices and save them for subsequent use after the server completes expansion (e.g., increasing the number of server instances) and contraction (e.g., reducing the number of server instances) and removes the insufficient performance state and runs smoothly, for subsequent use. According to the above health model 221, performance benchmark database 222, and policy warehouse 223, the data analysis module 22 can summarize the user experience data and server performance data, determine whether to expand or contract the server according to the user experience data and the server performance data, and determine the specific number of server instances to be increased or decreased.

[0064] The execution module 23 is used to execute the expansion and contraction actions of the server, and increase or decrease the instance nodes of the server according to the specific number of server instances to be increased or decreased.

[0065] In the embodiments of the present application, an instance node (referred to as an instance) may include the most basic computing components such as a CPU, memory, operating system, network, and disk, and may be understood as the smallest unit for providing computing services on the server side.

[0066] Figure 7 Schematic diagram of a deployment of the device for implementing the resource scheduling method provided in the embodiment of the present application. Figure 7 As shown, the client data acquisition module 211 can be integrated with the first-launched application and installed and deployed in the terminal device 11; the server data acquisition module 212 can be installed and deployed in the server 12 of the application, such as the background server, server cluster or cloud server of the application; the data analysis module 22 and the execution module 23 can be deployed in the server 12, for example, an instance node is allocated in the cloud server, and the data analysis module 22 and the execution module 23 are deployed in the instance node, so that other instance nodes used to provide services for the application are scheduled through the instance node, thereby realizing the expansion and reduction of the server.

[0067] The present application provides a resource scheduling method, such as Figure 8 As shown, the method may include the following steps S101-S108:

[0068] Step S101: The data analysis module obtains user experience data of the application from the client data collection module.

[0069] like Fig. 9 As shown, the client data collection module may include a data collection software development kit (SDK) integrated with the application and installed in the terminal device. The data collection SDK can obtain the user experience data generated by the application through an application programming interface (API) call and / or monitoring logs.

[0070] For example, when the user experience data is obtained by API call, the data collection SDK may include a pre-set user experience data reporting API. After the application collects the user experience data, it can report the user experience data to the data collection SDK by calling the user experience data reporting API. In the specific implementation, the application can call the user experience data reporting API regularly according to the preset reporting cycle, such as 1 minute, 2 minutes, 3 minutes, etc., and report the user experience data to the data collection SDK regularly; or, the application can also call the user experience data reporting API in real time to report the user experience data to the data collection SDK in real time; or, the data collection SDK can also send an instruction to the application when the user experience data needs to be collected, so that the application calls the user experience data reporting API according to the instruction and reports the user experience data to the data collection SDK. In the embodiment of the present application, the advantage of the API call is that after the application collects the user experience data, the user experience data can be temporarily cached in the random access memory (RAM) of the terminal device, that is, in the memory, without the need to write the user experience data to the flash memory (flash memory) or disk of the terminal device, so the performance is higher.

[0071] For example, when using log monitoring to obtain user experience data, the application can generate a log file containing the user experience data and save the log file in a preset directory of the flash memory or disk of the terminal device. The data collection SDK can monitor the log file or the directory where the log file is located, monitor whether the log file is updated and read the updated user experience data in the log file. In a specific implementation, the data collection SDK can read the log file regularly according to a preset reading cycle, such as 1 minute, 2 minutes, 3 minutes, etc., to regularly collect user experience data; or, the data collection SDK can also read the log file in real time to collect user experience data in real time.

[0072] In an embodiment of the present application, the data collection SDK can interact with the data analysis module through transmission protocols such as hypertext transfer protocol secure (HTTPS) and hypertext transfer protocol (HTTP). For example, when the HTTPS protocol is used for interaction, the data collection SDK can report the user experience data to the data analysis module by calling the HTTPS interface pre-configured by the data analysis module. For example, the data collection SDK can regularly call the HTTPS interface according to a preset reporting period, such as 1 minute, 2 minutes, 3 minutes, etc., to report the user experience data to the data analysis module; or, the data collection SDK can also call the HTTPS interface in real time to report the user experience data to the data analysis module in real time.

[0073] Step S102: the data analysis module obtains the server performance data of the server from the server data collection module.

[0074] like Fig.10 As shown, the server-side data collection module may include a data collection software agent running on the server. The data collection agent may obtain the server-side performance data by calling an API and / or monitoring logs.

[0075] For example, when the server performance data is obtained by API call, the data collection agent may include a pre-set server performance data reporting API. After the server collects the server performance data, it can report the server performance data to the data collection agent by calling the server performance data reporting API. In the specific implementation, the server can call the server performance data reporting API regularly according to the preset reporting cycle, such as 1 minute, 2 minutes, 3 minutes, etc., and report the server performance data to the data collection agent regularly; or, the server can also call the server performance data reporting API in real time, and report the server performance data to the data collection agent in real time; or, the data collection agent can also send an instruction to the server when it is necessary to collect the server performance data, so that the server calls the server performance data reporting API according to the instruction and reports the server performance data to the data collection agent. In the embodiment of the present application, the advantage of API calling is that after the server collects the server performance data, it can temporarily cache the server performance data in the random access memory RAM of the terminal device without writing the server performance data to the disk, so the performance is higher.

[0076] For example, when the server performance data is obtained by log monitoring, the server can generate a log file containing the server performance data and save the log file in a preset directory of the local disk. The data collection agent can monitor the log file or the directory where the log file is located, monitor whether the log file is updated and read the updated server performance data in the log file. In a specific implementation, the data collection agent can read the log file regularly according to a preset reading cycle, such as 1 minute, 2 minutes, 3 minutes, etc., to regularly collect server performance data; or, the data collection agent can also read the log file in real time to collect server performance data in real time.

[0077] In the embodiment of the present application, the data acquisition agent can interact with the data analysis module through transmission protocols such as HTTPS and HTTP. For example, when the HTTPS protocol is used for interaction, the data acquisition agent can report the server performance data to the data analysis module by calling the HTTPS interface pre-configured by the data analysis module. For example, the data acquisition AGENT can regularly call the HTTPS interface according to a preset reporting period, such as 1 minute, 2 minutes, 3 minutes, etc., to report the server performance data to the data analysis module; or, the data acquisition agent can also call the HTTPS interface in real time to report the server performance data to the data analysis module in real time.

[0078] It should be noted that, in the embodiment of the present application, step S101 and step S102 occur in parallel, in no particular order, that is, the data analysis module will simultaneously receive user experience data and server performance data from the terminal device and the server, and summarize and analyze the received data.

[0079] Step S103: The data analysis module determines whether the server has insufficient performance based on the user experience data and the server performance data.

[0080] In a specific implementation, the data analysis module can use a pre-set health model to determine whether the server has performance deficiencies. Fig.11It is a structural diagram of the health model shown in the embodiment of the present application. The health model may include three parts: a user experience data model, a server performance data model, and a health threshold. Among them, the user experience data model can be used to record various indicator values ​​in the user experience data, such as: the interface freeze time of the application, the application delay, the interface call delay of the application, the interface call success rate, the number of times the application interface is unresponsive, etc. The server performance data model can be used to record various indicator values ​​in the server performance data, such as: CPU utilization, memory utilization, network I / O interface traffic, data throughput of the server, interface call delay of the server, interface call success rate of the server, etc. Among them, the server performance data model can divide the index values ​​recorded by it into two categories, one is resource-type indicator values, such as CPU utilization, memory utilization and network I / O interface traffic, and the other is business performance-type indicator values. For example, the data throughput of the server, the interface call delay of the server, and the interface call success rate of the server. The health threshold may include a threshold corresponding to each indicator value, and the threshold may be used to evaluate user experience data and server performance data to determine whether the server has insufficient performance or excessive performance.

[0081] Optionally, the health threshold can also be divided into two types of thresholds, such as a latency threshold and a resource occupancy threshold, wherein the latency threshold corresponds to each indicator value in the user experience data and part of the indicator values ​​in the server performance data, and the resource occupancy threshold corresponds to another part of the indicator values ​​in the server performance data.

[0082] For example, a configuration of a health threshold is shown in Table 1 (where ms stands for milliseconds):

[0083]

[0084] Table 1

[0085] In the embodiment of the present application, the data analysis module can match one or more indicator values ​​in the user experience data and / or the server performance data with their corresponding thresholds based on the above health model, and determine whether the server has insufficient performance based on the matching results. Specifically, as long as at least one indicator value in the user experience data and / or the server performance data exceeds the range defined by its corresponding threshold, it is considered that the server has insufficient performance.

[0086] For example, when the threshold of application delay is 300ms, if the delay of the application is greater than 300ms, the server performance is considered insufficient; when the threshold of interface freeze time is 1500ms, if the interface freeze time of the application is greater than 1500ms, the server performance is considered insufficient; when the threshold of application interface call delay is 300ms, if the application interface call delay is greater than 300ms, the server performance is considered insufficient; when the threshold of application interface call success rate is 80%, if the application interface call success rate is less than 80%, the server performance is considered insufficient; when the threshold of application unresponsiveness is 3 times, if the application unresponsiveness is greater than 3 times, the server performance is considered insufficient; When the threshold of the server's interface call delay is 300ms, if the server's interface call delay is greater than 300ms, the server's performance is considered insufficient; when the threshold of the server's interface call success rate is 80%, if the server's interface call success rate is less than 80%, the server's performance is considered insufficient; when the threshold of the server's CPU usage is 80%, if the server's CPU usage is greater than 80%, the task server's performance is insufficient; when the threshold of the network I / O interface traffic is 900Mbps, if the network I / O interface traffic is greater than 900Mbps, the server's performance is insufficient; when the threshold of the server's data throughput is 900Mbps, if the server's data throughput is greater than 900Mbps, the server's performance is insufficient.

[0087] In addition, if the data analysis module determines that the server has no performance deficiency through the above method, it can also determine whether the server has performance surplus based on the current number of instance nodes on the server and the performance benchmark data performance of the server. According to the content previously described in the embodiment of the present application, the performance benchmark data performance can be stored in the performance benchmark database of the data analysis module. The performance benchmark data performance records the number of terminal devices that a single instance node on the server can support. Then, in one implementation method, as shown in the following formula ①, the data analysis module can subtract 1 from the current number of instance nodes N0 on the server and multiply it by the performance benchmark data performance, and multiply the resulting product by the number of terminal devices currently online N. online Compare, if the product is greater than the number of terminal devices currently online N online , it means that the server has excess performance.

[0088] Excess server performance: (N0-1)* performance > N online ①

[0089] For example, if the current number of instance nodes on the server is N0 = 10, the number of terminal devices that a single instance node can support is performance = 1000, and the number of terminal devices currently online is N online =8000, then, according to the above formula:

[0090] (10-1)*1000=9000>8000 Therefore, the server has excess performance.

[0091] For example, if the current number of instance nodes on the server is N0 = 10, the number of terminal devices that a single instance node can support is performance = 1000, and the number of terminal devices currently online is N online =9500, then, according to the above formula:

[0092] (10-1)*1000=9000<9500 Therefore, there is no excess performance on the server side.

[0093] It should be noted that the performance benchmark database in the embodiment of the present application may include multiple performance benchmark data, each performance benchmark data corresponds to an application, and indicates the number of terminal devices that can be supported when a single instance node acts as the server of the application.

[0094] Fig.12 This is the application scenario when the performance benchmark database includes multiple performance benchmark data. Fig.12 As shown, the server side of the application can be built in the cloud server. Generally speaking, the cloud server provider will divide the cloud server resources into a large number of instance nodes, and then allocate the instance nodes to different users. Therefore, the cloud server may have multiple application server sides. In this case, if the data analysis module and execution module in the device of the embodiment of the present application are built in the cloud server, the method of the embodiment of the present application can schedule the server side resources of multiple applications. In order to achieve this purpose, the performance benchmark database needs to include multiple performance benchmark data, corresponding to different applications.

[0095] For example, the performance benchmark database may have the following data structure (each row field corresponds to a performance benchmark data):

[0096] {"appId":"xxxxxxxx","performance":"2000","growthIndex","0.99"}

[0097] {"appId":"yyyyyyyy","performance":"1500","growthIndex","0.98"}

[0098] {"appId":"zzzzzzzzz","performance":"1500","growthIndex","0.98"}

[0099] …

[0100] Each row in the performance benchmark database includes three fields, constituting a set of data, namely: an application identifier appId, which is used to identify different applications. Different applications have different appIds, and appId can be a string composed of at least one of numbers, letters and symbols; performance benchmark data performance, which represents the number of terminal devices running the group of applications supported by a single instance node; a growth coefficient growthIndex, which is used to indicate the number of terminal devices that can actually be increased after adding an example node; generally speaking, due to system loss and other reasons, the growth coefficient is usually less than or equal to 1 and greater than 0; for example, when the growth coefficient growthIndex = 0.99, if performance = 1000, then for each additional instance node, the number of terminal devices actually increased by 1000*0.99 = 990.

[0101] Step S104, when the performance of the server is insufficient, the data analysis module determines the number of instance nodes that need to be added to the server according to the number of terminal devices currently online and preset performance benchmark data.

[0102] In the specific implementation, as shown in formula ②, the data analysis module can calculate the number of terminal devices currently online N online Divide by the performance benchmark data performance, and then subtract the number of instance nodes on the server N0 to get the predicted number of server instance nodes that need to be adjusted N.

[0103] N=N online / performance - N0 ②

[0104] Then, the data analysis module can ultimately decide the number of server instance nodes that need to be increased or decreased based on the value of N.

[0105] An alternative decision-making process is shown below (1)-(4):

[0106] (1) When the predicted number of server instance nodes that need to be adjusted is greater than or equal to 1, that is, N=[1,∞+), the predicted number of server instance nodes that need to be adjusted is rounded up as the number of instance nodes that need to be added on the server.

[0107] For example, if the current number of instance nodes on the server is N0 = 10, the performance benchmark data performance = 1000, and the number of terminal devices currently online is N online =11200, then, according to the above formula:

[0108] N=11200 / 1000-10=1.2. The number of instance nodes that need to be added on the server side is rounded to 1.

[0109] For example, if the current number of instance nodes on the server is N0 = 10, the performance benchmark data performance = 1000, and the number of terminal devices currently online is N online =12300, then, according to the above formula:

[0110] N=12300 / 1000-10=2.3. The number of instance nodes that need to be added on the server side is rounded to 2.

[0111] (2) When the predicted number of server instance nodes that need to be adjusted is less than or equal to -1, that is, N = (∞-, -1], the predicted number of server instance nodes that need to be adjusted is rounded up as the number of server instance nodes that need to be reduced.

[0112] For example, if the current number of instance nodes on the server is N0 = 10, the performance benchmark data performance = 1000, and the number of terminal devices currently online is N online =8888, then, according to the above formula:

[0113] N=8800 / 1000-10=-1.2. Take the absolute value and round it to get the number of server instance nodes that need to be reduced, which is 1.

[0114] For example, if the current number of instance nodes on the server is N0 = 10, the performance benchmark data performance = 1000, and the number of terminal devices currently online is N online =7650, then, according to the above formula:

[0115] N=7650 / 1000-10=-2.35. Take the absolute value and round it to get the number of server instance nodes that need to be reduced, which is 2.

[0116] (3) When the predicted number of server instance nodes that need to be adjusted is less than or equal to 0 and less than 1, that is, N = [0, 1), it is determined not to adjust the number of server instance nodes. For example, if the current number of server instance nodes N0 = 10, the performance benchmark data performance = 1000, and the number of terminal devices currently online N online =1050, then, according to the above formula:

[0117] If N=1050 / 1000-10=0.05, it is determined that the number of server instance nodes will not be adjusted.

[0118] (4) When the predicted number of server instance nodes that need to be adjusted is greater than -1 and less than 0, that is, N = (-1, 0), it is determined not to adjust the number of server instance nodes. For example, if the current number of server instance nodes N0 = 10, the performance benchmark data performance = 1000, and the number of terminal devices currently online N online =950, then, according to the above formula:

[0119] If N=950 / 1000-10=-0.05, it is determined that the number of server instance nodes will not be adjusted.

[0120] Further, when the data analysis module determines that the number of server instance nodes needs to be adjusted, a response instruction can be sent to the execution module to instruct the execution module to perform a specific action of adjusting the number of server instance nodes. The instruction sent by the data analysis module to the execution module can include a first instruction to increase the number of server instance nodes and a second instruction to reduce the number of server instance nodes.

[0121] In a specific implementation, when the data analysis module determines that the number of instance nodes that needs to be increased on the server side, the data analysis module executes step S105, causing the execution module to execute step S106.

[0122] Step S105: the data analysis module sends the first instruction to the execution module.

[0123] The first instruction may include the number of instance nodes that the server needs to add as determined by the data analysis module.

[0124] When the device of the embodiment of the present application is used to schedule server resources of multiple applications, the first instruction may also include the appId of the application corresponding to the server to which the instance node needs to be added, so that the execution module can know which application's server needs to add an instance node.

[0125] For example, when the data analysis module determines that the server of the game "XXXX" needs to be added, the appId of the game is xxxxxxxx, and the number of instance nodes addNodeNumber that the server needs to add is 2, then the first instruction may include the following content:

[0126] {"appId":"xxxxxxxx","addNodeNumber":"2"}

[0127] Step S106 : the execution module responds to the first instruction and increases the instance nodes of the server according to the number of instance nodes that the server needs to increase.

[0128] In a specific implementation, the execution module may call a pre-set application program interface related to adding instance nodes to create a new instance node. For example, when addNodeNumber is 2, two new instance nodes are created and added to the production environment of the server, so that the newly added instance nodes and the original instance nodes of the server can serve the application together.

[0129] In addition, when the data analysis module determines that the number of server instance nodes needs to be reduced, the data analysis module executes step S107, so that the execution module executes step S108.

[0130] Step S107: the data analysis module sends the second instruction to the execution module.

[0131] The second instruction may include the number of instance nodes that the server needs to reduce as determined by the data analysis module.

[0132] When the device of the embodiment of the present application is used to schedule server resources of multiple applications, the second instruction may also include the appId of the application corresponding to the server of the instance node that needs to be reduced, so that the execution module can know which application's server needs to reduce the instance node.

[0133] For example, when the data analysis module determines that the server of the game "XXXX" needs to be added, the appId of the game is xxxxxxxx, and the number of instance nodes that the server needs to increase reduceNodeNumber is 3, then the first instruction may include the following content:

[0134] {"appId":"xxxxxxxx","reduceNodeNumber":"3"}

[0135] Step S108 : the execution module responds to the second instruction and increases the instance nodes of the server according to the number of instance nodes that the server needs to increase.

[0136] In a specific implementation, the execution module may call a pre-set application program interface related to reducing instance nodes, and release a specified number of instance nodes from the current instance nodes of the server. For example, when reduceNodeNumber is 3, 3 instance nodes are released, so that these 3 instance nodes no longer serve the application program. The process of releasing instance nodes may include, for example: allocating the tasks being executed in the 3 instance nodes to be released to other instance nodes, and then releasing the 3 instance nodes, so that these 3 instance nodes no longer serve the application program.

[0137] It should be noted that the performance benchmark data in the embodiments of the present application may be variable data, and its initial value may be determined by the technician based on experience, or by the technician testing the capacity of the server in a test environment. For example, before the application is first launched on the application market, the technician may perform a stress test on the server of the application in a test environment to determine the number of terminal devices that a single instance node can support in the test environment, and use this number as the initial value of the performance benchmark data.

[0138] It is understandable that although the test environment can simulate the working conditions of the server in the production environment, since the test environment is not exactly the same as the production environment, there may be certain differences between the performance benchmark data determined in the test environment and the performance benchmark data in the production environment. Therefore, if the performance benchmark data determined in the test environment is always used in the production environment, it may cause certain errors in the resource scheduling of the server. In order to eliminate errors and improve the accuracy of resource scheduling, the embodiment of the present application also corrects the performance benchmark data based on the user experience data and server performance data collected in the production environment. The correction process is as follows: Fig.13 As shown, the following steps S201 to S204 may be included:

[0139] Step S201: The data analysis module multiplies the number of instance nodes of the server by the performance benchmark data to obtain the number of terminal devices theoretically supported by the server.

[0140] Right now:

[0141] The number of terminal devices that the server theoretically supports S = the number of instance nodes N0 * performance benchmark data performance

[0142] For example, if the current number of instance nodes N0 of the server is 10, and the performance benchmark data performance=1000, then according to the above formula, the number of terminal devices theoretically supported by the server is S=10*1000=10000.

[0143] Step S202: The data analysis module determines whether the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server.

[0144] Step S203: If the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server, it is determined whether the server has insufficient performance.

[0145] It is understandable that if the performance data value is reasonable, then when the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server, the server should not have insufficient performance. If the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server, but the server has insufficient performance, it means that the number of terminal devices actually supported by the server is smaller than the number of terminal devices theoretically supported, that is, the current performance benchmark data value is too large.

[0146] Step S204: If the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server, and the server has insufficient performance, the data analysis module reduces the value of the performance benchmark data until the server is free from insufficient performance.

[0147] In a specific implementation, the data analysis module can reduce the value of the performance benchmark data according to the following formula:

[0148] The performance benchmark data after reduction = the current performance benchmark data (before reduction) * K

[0149] Wherein, K is an empirical coefficient, and its value is greater than 0 and less than 1, and its preferred value is 0.8≤K<1.

[0150] For example, when the performance benchmark data before reduction is 1000 and K is 0.9, the performance benchmark data after one reduction is 1000*0.9=900.

[0151] After reducing the performance benchmark data, the data analysis module may redetermine the number of instance nodes that need to be added based on the reduced performance benchmark data, and the execution module may further increase the instance nodes on the server side based on the redetermined number of instance nodes that need to be added.

[0152] For example, if the current number of instance nodes on the server is N0 = 10, the previous performance benchmark data performance = 1000, and the current number of online terminal devices N online=11200, then the number of instance nodes that need to be added is 1, and the number of instance nodes on the server side increases to 11. If calculated according to the increased performance benchmark data performance=900, then the number of instance nodes that need to be added is 2, and the number of instance nodes on the server side increases to 12. Therefore, after reducing the value of the performance benchmark data, the method of the embodiment of the present application can add more instance nodes to the server side, thereby further alleviating the insufficient performance state of the server side.

[0153] It should be noted that the above-mentioned method steps S101 to S107 and steps S201 to S204 of the example of the present application can be repeated periodically, for example, once every 3 minutes, so as to achieve periodic and continuous adjustment of the number of instance nodes on the server based on user experience data and server performance data when the application (and its new version) is first launched, and periodic and continuous correction of performance benchmark data until the server is freed from insufficient performance and runs smoothly.

[0154] Furthermore, after the server is freed from the insufficient performance state and runs smoothly, the data analysis module can obtain the number of terminal devices that the server can support under the current number of instance nodes, that is, the number that will not cause insufficient performance on the server. Then, the data analysis module can save the number of instance nodes and the number of terminal devices that they can support to a policy warehouse, which includes the number of terminal devices that the server of at least one application can support under different numbers of instance nodes.

[0155] For example, the data structure of the policy repository may be as follows:

[0156] {"appId":"xxxxxxxx","nodeNumber":"1","userNumber","10000"}

[0157] {"appId":"xxxxxxxx","nodeNumber":"2","userNumber","19000"}

[0158] {"appId":"xxxxxxxx","nodeNumber":"3","userNumber","28000"}

[0159] {"appId":"yyyyyyyy","nodeNumber":"10","userNumber","500000"}

[0160] {"appId":"yyyyyyyy","nodeNumber":"11","userNumber","540000"}

[0161] …

[0162] Each row in the policy repository includes three fields, forming a set of data, namely: application identifier appId, instance node number nodeNumber, and supported terminal device number userNumber.

[0163] After the policy warehouse records the number of terminal devices that each application server can support under different numbers of instance nodes, such as Fig.14 As shown, in the subsequent operation of the application server, the data analysis module can directly obtain from the policy warehouse how many instance nodes are needed to support the number of terminal devices currently online, and then determine the number of instance nodes that need to be increased.

[0164] For example, suppose that the server of an application appId = xxxxxxxx currently has 2 instance nodes. If the number of online terminal devices of the application reaches 20,000 at a certain moment, the server will have insufficient performance. At this time, the data analysis module can query the number of instance nodes corresponding to 20,000 terminal devices in the policy warehouse. After querying, it is found that 2 instance nodes can support 19,000 terminal devices, and 3 instance nodes can support 28,000 terminal devices. Therefore, the data analysis module can determine to add another instance node so that the server has 3 instance nodes.

[0165] For example, suppose that a server of an application appId = xxxxxxxx currently has 2 instance nodes. If the number of online terminal devices of the application is 10,000 at a certain moment, the server will have excess performance. At this time, the data analysis module can query the number of instance nodes corresponding to 10,000 terminal devices in the policy warehouse. After querying, it is found that the server only needs 1 instance node to support 10,000 terminal devices, so the data analysis module can determine to reduce 1 instance node so that the server has 1 instance node.

[0166] Therefore, the data analysis module omits the process of step S101 to step S104 in the embodiment of the present application by directly querying the policy warehouse, shortens the cycle of expanding or shrinking the server, and improves efficiency.

[0167] It can be seen from the above technical solutions that the resource scheduling method provided in the embodiment of the present application can collect user experience data of the terminal device and server performance data of the server when the application is first launched, and then comprehensively judge whether the server has performance deficiencies based on the user experience data and server performance data. When performance deficiencies occur on the server, the number of instance nodes that need to be added is accurately determined based on the performance benchmark data, thereby achieving timely and accurate capacity expansion of the server, eliminating the performance deficiencies of the server, avoiding server downtime, and improving the user experience when the application is first launched.

[0168] In the embodiments provided by the present application, the various schemes of the resource scheduling method provided by the present application are introduced from the perspective of the device or apparatus itself, and from the perspective of the interaction between the devices or apparatuses. It is understandable that each device or apparatus, such as the above-mentioned resource scheduling apparatus, terminal equipment and server, includes a hardware structure and / or software module corresponding to each function in order to realize the above-mentioned functions. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0169] Fig.15 is a schematic diagram of a resource scheduling device provided in an embodiment of the present application. In one embodiment, the resource scheduling device can be Fig.15 The hardware devices shown in the figure implement the corresponding functions. Fig.15 As shown, the resource scheduling device may include: a transceiver 401 , a memory 402 , and a processor 403 .

[0170] In one embodiment, the processor 403 may include one or more processing units, for example, the processor 403 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0171] The memory 402 is coupled to the processor 403 and is used to store various software programs and / or multiple sets of instructions. In some embodiments, the memory 402 may include a high-speed random access memory and may also include a non-volatile memory. The memory 402 may also store an operating system, such as an embedded operating system such as ANDROID, IOS, WINDOWS, or LINUX.

[0172] In one embodiment, the transceiver 401 is a network interface controller (NIC) including a twisted pair interface (eg RJ45) or a fiber optic interface, so that the device can access a local area network (LAN) or a wide area network (WAN) via a wired connection.

[0173] When the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is used to perform the following steps: obtaining user experience data of the target application APP from a terminal device on which the target APP is installed, and obtaining server performance data from the server of the target APP, wherein the user experience data includes data related to the server performance generated during the operation of the target APP, and the server performance data includes resource usage data and / or interface performance data of the server; judging whether the server has insufficient performance based on the user experience data and the server performance data; when the server has insufficient performance, determining the number of instance nodes that the server needs to add based on the number of terminal devices currently online and preset performance benchmark data, wherein the performance benchmark data includes the number of terminal devices supported by each instance node; and increasing the instance nodes of the server based on the number of instance nodes that the server needs to add.

[0174] In one embodiment, the user experience data is collected by a data collection software development kit SDK installed on a terminal device; the data collection SDK obtains the user experience data reported by the target APP through its own user experience data reporting application program interface API, or the target APP is used to store the generated user experience data in a first log file, and the data collection SDK collects the user experience data by monitoring the first log file or the directory where the first log file is located.

[0175] In one embodiment, the server performance data is collected by a data collection software agent installed on the server; the data collection agent obtains the server performance data reported by the server through its own performance data reporting API, or the server is used to store the generated server performance data in a second log file, and the data collection agent is used to monitor the second log file or the directory where the second log file is located to collect the server performance data.

[0176] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps to determine whether the server has performance deficiencies based on the user experience data and the server performance data: match one or more indicator values ​​in the user experience data and / or the server performance data with their corresponding thresholds, and determine whether the server has performance deficiencies based on the matching results.

[0177] In one embodiment, when at least one indicator value in the user experience data and / or the server performance data exceeds the range defined by its corresponding threshold value, the server performance is insufficient.

[0178] In one embodiment, when the product of the number of instance nodes on the server minus 1 and the performance benchmark data is greater than the number of terminal devices currently online, the server has excess performance.

[0179] In one embodiment, the user experience data and / or server performance data include one or more delay class indicator values ​​and one or more resource occupancy class indicator values, each delay class indicator value corresponds to a delay class threshold, and each resource occupancy class indicator value corresponds to a resource occupancy class threshold.

[0180] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps to determine the number of instance nodes that need to be added to the server based on the number of terminal devices currently online and preset performance benchmark data: divide the number of terminal devices currently online by the performance benchmark data, and then subtract the number of instance nodes on the server to obtain the predicted number of server instance nodes that need to be adjusted; when the predicted number of server instance nodes that need to be adjusted is greater than or equal to 1, round the predicted number of server instance nodes that need to be adjusted as the number of instance nodes that need to be added to the server.

[0181] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps: when the predicted number of server instance nodes that need to be adjusted is less than or equal to -1, the absolute value of the predicted number of server instance nodes that need to be adjusted is rounded as the number of server instance nodes that need to be reduced.

[0182] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps: multiply the number of instance nodes on the server side by the performance benchmark data to obtain the number of terminal devices theoretically supported by the server side; if the number of terminal devices currently online is less than the number of terminal devices theoretically supported by the server side, and the server side has insufficient performance, then reduce the value of the performance benchmark data.

[0183] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps to reduce the value of the performance benchmark data: periodically reduce the value of the performance benchmark data, and the value of the performance benchmark data after each reduction is equal to the value of the performance benchmark data before the reduction multiplied by an empirical coefficient, and the empirical coefficient is greater than 0 and less than 1.

[0184] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps: when the server is released from the insufficient performance state, the number of terminal devices that can be supported by the current number of instance nodes of the server is saved in the policy warehouse, and the policy warehouse includes the number of terminal devices that the server can support under different numbers of instance nodes.

[0185] In one embodiment, when the software program and / or multiple groups of instructions in the memory 402 are executed by the processor 403, the device is also used to perform the following steps: when the server performance is insufficient, determine the number of instance nodes to be added from the policy warehouse based on the number of terminal devices currently online.

[0186] In another embodiment, the resource scheduling device can Figure 6 The software modules shown in the figure implement the corresponding functions. Figure 6 As shown, the resource scheduling device may include: a client data acquisition module, a server data acquisition module, a data analysis module and an execution module. Among them, the client data acquisition module is used to send the user experience data of the target APP to the resource scheduling device, and the user experience data includes the data related to the server performance generated during the operation of the target APP; the server data acquisition module is used to send the server performance data to the data analysis module, and the server performance data includes the resource usage data and / or interface performance data of the server; the data analysis module is used to determine whether the server has insufficient performance based on the user experience data and the server performance data; the data analysis module is also used to determine the number of instance nodes that the server needs to increase based on the number of terminal devices currently online and the preset performance benchmark data when the server performance is insufficient, and the performance benchmark data includes the number of terminal devices supported by each instance node; the execution module is used to increase the instance nodes of the server according to the number of instance nodes that the server needs to increase.

[0187] The present application also provides a network system, such as Fig.16 As shown, the network system includes: a server 501 of a target APP, at least one terminal device 502 with the target APP installed, and a resource scheduling device 503; the terminal device 502 is used to send user experience data of the target APP to the resource scheduling device 503, and the user experience data includes data related to the performance of the server 501 generated during the operation of the target APP; the server 501 is used to send server 501 performance data to the resource scheduling device 503, and the server 501 performance data includes resource usage data and / or interface performance data of the server 501; the resource scheduling device 503 is used to determine whether the server 501 has insufficient performance based on the user experience data and the server 501 performance data; the resource scheduling device 503 is also used to determine the number of instance nodes that the server 501 needs to increase according to the number of terminal devices 502 currently online and preset performance benchmark data when the server 501 has insufficient performance, and the performance benchmark data includes the number of terminal devices 502 supported by each instance node; the resource scheduling device 503 is also used to increase the instance nodes of the server 501 according to the number of instance nodes that the server 501 needs to increase.

[0188] The embodiment of the present application also provides a computer-readable storage medium, in which instructions are stored. When the computer-readable storage medium is run on a computer, the computer executes the above-mentioned methods.

[0189] The embodiment of the present application also provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the above-mentioned methods.

[0190] The embodiment of the present application also provides a chip system, Fig.17 6 is a schematic diagram of the structure of the chip system. The chip system includes a processor 601, which is used to support the above-mentioned device to implement the functions involved in the above-mentioned aspects, for example, to generate or process the information involved in the above-mentioned method. In a possible design, the chip system also includes a memory 602, which is used to store computer instructions 603 and data necessary for the resource scheduling device. The chip system can be composed of chips, or it can include chips and other discrete devices.

[0191] The above specific implementation methods further explain in detail the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above are only specific implementation methods of the embodiments of the present application and are not used to limit the protection scope of the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A resource scheduling method, characterized in that: include: Acquire user experience data of a target APP, and acquire server performance data from a server of the target APP, wherein the user experience data includes data related to the performance of the server generated during the operation of the target APP, and the server performance data includes resource usage data and / or interface performance data of the server; Determining whether the server has insufficient performance based on the user experience data and the server performance data; When the performance of the server is insufficient, the number of instance nodes that need to be added by the server is determined according to the number of terminal devices currently online and preset performance benchmark data, wherein the performance benchmark data includes the number of terminal devices supported by each instance node; The instance nodes of the server are increased according to the number of instance nodes that need to be increased by the server.

2. The resource scheduling method according to claim 1, characterized in that: The user experience data is collected by a data collection software development kit SDK installed on the terminal device.

3. The resource scheduling method according to claim 2, characterized in that: The data collection SDK obtains the user experience data reported by the target APP through its own user experience data reporting application program interface API.

4. The resource scheduling method according to claim 2, characterized in that: The target APP is used to store the generated user experience data in a first log file, and the data collection SDK collects the user experience data by monitoring the first log file or the directory where the first log file is located.

5. The resource scheduling method according to claim 1, characterized in that: The server performance data is collected by a data collection software agent installed on the server.

6. The resource scheduling method according to claim 5, characterized in that: The data collection agent obtains the server performance data reported by the server through its own performance data reporting API.

7. The resource scheduling method according to claim 5, characterized in that: The server is used to store the generated server performance data in a second log file, and the data collection agent is used to monitor the second log file or the directory where the second log file is located to collect the server performance data.

8. The resource scheduling method according to any one of claims 1 to 7, characterized in that: The determining whether the server has performance deficiencies based on the user experience data and the server performance data includes: matching one or more indicator values ​​in the user experience data and / or the server performance data with corresponding thresholds, and determining whether the server has performance deficiencies based on the matching results.

9. The resource scheduling method according to any one of claims 8 to 10, characterized in that: The user experience data and / or the server performance data include one or more delay class indicator values ​​and one or more resource occupancy class indicator values, each delay class indicator value corresponds to a delay class threshold, and each resource occupancy class indicator value corresponds to a resource occupancy class threshold.

10. The resource scheduling method according to claim 14, characterized in that: The reducing the value of the performance benchmark data includes: periodically reducing the value of the performance benchmark data, the value of the performance benchmark data after each reduction is equal to the value of the performance benchmark data before the reduction multiplied by an empirical coefficient, and the empirical coefficient is greater than 0 and less than 1.

11. A resource scheduling device, characterized in that: include: A transceiver, a memory and a processor; wherein the memory includes program instructions, and when the program instructions are executed by the processor, the device is used to perform the following steps: Acquire user experience data of a target APP, and acquire server performance data from a server of the target APP, wherein the user experience data includes data related to the performance of the server generated during the operation of the target APP, and the server performance data includes resource usage data and / or interface performance data of the server; Determining whether the server has insufficient performance based on the user experience data and the server performance data; When the performance of the server is insufficient, the number of instance nodes that need to be added by the server is determined according to the number of terminal devices currently online and preset performance benchmark data, wherein the performance benchmark data includes the number of terminal devices supported by each instance node; The instance nodes of the server are increased according to the number of instance nodes that need to be increased by the server.

12. The resource scheduling device according to claim 11, characterized in that: The user experience data is collected by a data collection software development kit SDK installed on the terminal device.

13. The resource scheduling device according to claim 11, characterized in that: The data collection SDK obtains the user experience data reported by the target APP through its own user experience data reporting application program interface API.

14. The resource scheduling device according to claim 11, characterized in that: The target APP is used to store the generated user experience data in a first log file, and the data collection SDK collects the user experience data by monitoring the first log file or the directory where the first log file is located.

15. The resource scheduling device according to any one of claims 11 to 14, characterized in that: The program instructions further cause the device to execute the following steps to determine whether the server has insufficient performance based on the user experience data and the server performance data: One or more indicator values ​​in the user experience data and / or the server performance data are matched with corresponding thresholds, and whether the server has performance deficiencies is determined based on the matching results.

Images