WO2015163915A1

WO2015163915A1 - Optimizing scaling based on real user experience

Info

Publication number: WO2015163915A1
Application number: PCT/US2014/035498
Authority: WO
Inventors: Rotem Steuer; Michael Gopshtein; Alon KOLET
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2014-04-25
Filing date: 2014-04-25
Publication date: 2015-10-29

Abstract

Optimizing scaling based on real user experience includes monitoring, using a real user monitor solution, application tiers, determining a priority level for each of the application tiers, identifying, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers, and scaling, according to a scaling plan, the application tiers based on the issues and the priority level for each of the application tiers.

Description

OPTIMIZING SCALING BASED ON REAL USER EXPERIENCE

BACKGROUND

[0001] Often, applications rescale their resource consumption to manage traffic loads and maintenance expenses. Upon peak periods or heavy traffic loads an application may rescale its resource consumption to avoid delays issues, performance issues, and availability issues. Upon idle periods, the application may rescale its resource consumption to reduce maintenance expenses.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The accompanying drawings illustrate various examples of the principles described herein and are a part of the specification. The examples do not limit the scope of the claims.

[0003] Fig. 1 is a diagram of an example of a system for optimizing scaling based on real user experience, according to one example of principles described herein.

[0004] Fig. 2 is a diagram of an example of a scaled down system, according to one example of principles described herein.

[0005] Fig. 3 is a diagram of an example of a scaled up system, according to one example of principles described herein.

[0006] Fig. 4 is a flowchart of an example of a method for optimizing scaling based on real user experience, according to one example of principles described herein. [0007] Fig. 5 is a flowchart of an example of a method for optimizing scaling based on real user experience, according to one example of principles described herein.

[0008] Fig. 6 is a diagram of an example of an optimizing system, according to one example of principles described herein.

[0009] Fig. 7 is a diagram of an example of an optimizing system, according to one example of principles described herein.

[0010] Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements.

DETAILED DESCRIPTION

[0011] To rescale the applications to meet the application's resource consumption demands, an application owner is to know when and how to trigger the scaling of the applications. In one example, the application owner may manually scale the applications. Manually scaling the applications involves the application owner determining which applications are to be rescaled and if an application is to be scaled up or scaled down. With hundreds of

applications, the application owner may improperly scale the applications. This can lead to delays, performance issues, availability issues, increased cost for application maintenance, as well as other complications.

[0012] The principles described herein include a method for optimizing scaling based on real user experience. Such a method includes monitoring, using a real user monitor solution, application tiers, determining a priority level for each of the application tiers, identifying, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers, and scaling, according to a scaling plan, the application tiers based on the issues and the priority level for each of the application tiers. Such a method allows scaling of the application's resources to be optimized by scaling the application tiers. As a result, delays, performance issues and availability issues are reduced as well as the cost for application maintenance.

[0013] In the present specification and in the appended claims, the term "resource" is meant to be understood broadly as a source that an application may use when accessing or processing data. In one example, a resource may be a server, a database, random access memory (RAM), central processing unit (CPU), other resources, or combinations thereof.

[0014] In the present specification and in the appended claims, the term "application tier" is meant to be understood broadly as a layer of functionality for an application. For example, a persistency tier is composed of database servers. A user interface (Ul) tier is composed of Web servers. A business brain tier is composed of application servers that handle calculations of the applications. In one example, if an application is a finance application, the application tier for the finance application is responsible for all the finance calculations, approximation, and predictions. In one example, if the application as a whole is a multi-tier module, each tier is composed of several servers which share the functionality load. Further, due to dependencies between different application tiers, some application tier may be considered as users for other application tier. For example, business logic brain tier servers, such as application servers, are the actual users of the persistency database tier since they request all the persistency and query request from the various databases. As a result, measuring the performance and availability of the database persistency tier as experience by business logic brain tier servers is considered as measuring the real user experience of the database persistency tier.

[0015] In the present specification and in the appended claims, the term "issue" is meant to be understood broadly as a current state of an application tier, as monitored by a real user monitor solution, in which the current state indicates a negative impact on the application tier. In one example, an issue may be a performance issue, an availability issues, a delay issues, other issues, or combinations thereof. As will be described below, an issue negatively impacts a user. In the present specification and in the appended claims, the term "priority level" is meant to be understood broadly as level of significance associated with an application tier. In one example, the priority level may be a range such as 0 to 10, where 0 represents the lowest priority level for an application tier and 10 represents the highest priority level for an application tier. In another example, the priority level may be symbolic such as lowest priority, less priority, more priority, and highest priority, among others.

[0016] Further, as used in the present specification and in the appended claims, the term "a number of or similar language is meant to be understood broadly as any positive number comprising 1 to infinity; zero not being a number, but the absence of a number.

[0017] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present systems and methods. It will be apparent, however, to one skilled in the art that the present apparatus, systems, and methods may be practiced without these specific details. Reference in the specification to "an example" or similar language means that a particular feature, structure, or characteristic described in connection with that example is included as described, but may not be included in other examples.

[0018] Referring now to the figures, Fig. 1 is a diagram of an example of a system for optimizing scaling based on real user experience, according to one example of principles described herein. As will be described below, an optimizing system is in communication with a network to monitor, using a real user monitor solution, application tiers. Further, the optimizing system identifies, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers. Further, the optimizing system scales, according to a scaling plan, the application tiers based on the issues and a priority level for each of the application tiers.

[0019] In one example, the system (100) includes a user device ( 12) with a display (110). In this example, a user device (112) may be used by a user to access applications (112) over a network (106). As will be described in other parts of this specification, the application tiers (114) may be layers of functionality for applications (112). Further, the applications (112) may use the resources (108) when accessing or processing data. In one example, a resource may be a server, a database, RAM, CPU, other resources, or combinations thereof. The more users that access the applications (112), the heavier the traffic load on the network (106). In one example, if the traffic load on the network (106) is excessive, this may cause issues such as performance issues, availability issues, delay issues, other issues, or combinations thereof for the application tiers (11 ).

[0020] The system (100) further includes an optimizing system (110). As will be described in other parts of this specification, the optimizing system (110) monitors, using a real user monitor solution, application tiers (114). In one example, the optimizing system (110) monitors all incoming and outgoing traffic to every application tier (1 4) and based on that measurement, the optimizing system (110) deduces and calculates performance and availability of the application tiers (114).

[0021] Further, the optimizing system (110) determines a priority level for each of the application tiers (114). In one example, the priority level may be based on determining a number of dependencies for each of the application tiers (114). In another example, the priority level may be based on determining the priority level set by an application owner for each of the application tiers (114).

[0022] The optimizing system (110) further identifies, based on monitoring the application tiers ( 14), issues associated with each of the application tiers (114), the issues representing current states of the application tiers (114), as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers (114). In one example, an issue may be a performance issue, an availability issue, a delay issue, other issues, or combinations thereof for the application tiers (114).

[0023] Further, the optimizing system (110) scales, according to a scaling plan, the application tiers (114) based on the issues and the priority level for each of the application tiers (114). Such a method allows scaling of the application's resources to be optimized by scaling the application tiers (114). As a result, delays, performance issues and availability issues are reduced as well as the cost for application maintenance. More information about the optimizing system (110) will be described later on in this specification.

[0024] While this example has been described with reference to the optimizing system being located over the network, the optimizing system may be located in any appropriate location according to the principles described herein. For example, the optimizing system may be located in a user device, a server, a datacenter, other locations, or combinations thereof.

[0025] While this example has been described with reference to one user device accessing the applications, any number of user devices may access the application. Depending on the users and the number of user devices, the traffic load may be increased or decreased. As a result, the optimizing system may scale the application tiers accordingly.

[0026] While this example has been described with reference to the application tiers being located over the network, the application tiers may be located in any appropriate location according to the principles described herein. For example, the application tiers may be located on the applications.

[0027] Fig. 2 is a diagram of an example of a scaled down system, according to one example of principles described herein. As mentioned above, an optimizing system is in communication with a network to monitor, using a real user monitor solution, application tiers. Further, the optimizing system identifies, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers. Further, the optimizing system scales, according to a scaling plan, the application tiers based on the issues and a priority level for each of the application tiers.

[0028] As illustrated in Fig. 2, the system (200) is scaled down. In one example, if no application tier is suffering from issues, the optimizing system of Fig. 1 may scale down. For example, scaling down may use less resources, servers, and services. Scaling down may take into consideration network volume and a concurrent amount of users on the network. In one example, again according to the highest priority level for each of the application tiers, the optimizing system of Fig. 1 will learn from the history of the monitoring for each application tier and deduce whether the system (200) can be scaled down.

[0029] In this example, the system (200) is scaled down to include a persistence tier database server (202), a business logic tier application server (204), and web tier web server (206). As a result, the cost for application maintenance is reduced without the network experiencing issues such as delays issues, performance issues, and availability issues.

[0030] Fig. 3 is a diagram of an example of a scaled up system, according to one example of principles described herein. As mentioned above, an optimizing system is in communication with a network to monitor, using a real user monitor solution, application tiers. Further, the optimizing system identifies, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers. Further, the optimizing system scales, according to a scaling plan, the application tiers based on the issues and a priority level for each of the application tiers.

[0031] As illustrated in Fig. 3, the system (300) is scaled up.

According to the analysis of the real user monitoring, the optimizing system of Fig. 1 understands which application tiers suffer from issues such as delays issues, performance issues, and availability issue. In one example, the analysis may be done according to a baseline or according to static thresholds. In the example of Fig. 3, the optimizing system of Fig. 1 scales up the system (300). This increases resources, servers instances, and/or services usages. As will be described in other parts of this specification, in those scenarios according to a priority level, the optimizing system of Fig. 1 focuses on a single application tier with the highest priority level set for scaling by the application owner that suffers from issues. As a result, this application tier is scaled up. [0032] In this example, the system (300) is scaled up to include two persistence tier database server (302), two business logic tier application server (304), and three web tier web server (306). As a result, issues such as delays issues, performance issues, and availability issues are reduced.

[0033] Fig. 4 is a flowchart of an example of a method for optimizing scaling based on real user experience, according to one example of principles described herein. In one example, the method (400) may be executed by the system (100) of Fig. 1. In other examples, the method (400) may be executed by other systems such as system 600 or system 700. In this example, the method (400) includes monitoring (401), using a real user monitor solution, application tiers, determining (402) a priority level for each of the application tiers, identifying (403), based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers, and scaling (404), according to a scaling plan, the application tiers based on the issues and the priority level for each of the application tiers.

[0034] As mentioned above, the method (400) includes monitoring (401). using a real user monitor solution, application tiers. In one example, the method (400) monitors all incoming and outgoing traffic to every application tier and based on the traffic, the method (400) deduces performance and availability for each application tier. As a result, the method (400) monitors the current state of the application tiers.

[0035] In one example, monitoring, using the real user monitor solution, the application tiers includes monitoring the application tiers using a sniffer based solution. For example, the sniffer based solution may sniff the traffic and perform an analysis of the traffic. In one example, the sniffer based solution may use a real user experience manager (RUM) tool. The RUM tool is a passive monitoring technology that records all user interaction with a website or client interacting with a server, application tiers, or database based application as data. The RUM tool monitors the actual user interaction with a website or an application of interest to determine if users are being served quickly, error free and if not which part of a business process is failing. The data is used to determine the actual service-level quality delivered to end-users and to detect errors or slowdowns on web sites. The data may also be used to determine if changes that are promulgated to application tiers has a desired effect or causes issues.

[0036] In another example, monitoring, using the real user monitor solution, the application tiers includes monitoring the application tiers using a server agent code injection solution. In one example, the server agent code injection solution interjects computer program code on a server such that the server understands the traffic on the server. In one example, a diagnostic tool may be used to aid the server agent code injection solution in analyzing the traffic on the server.

[0037] In yet another example, monitoring, using the real user monitor solution, the application tiers includes monitoring the application tiers using a client instrumentation solution. In one example, the client instrumentation solution injects computer program code into every client. Further the client instrumentation solution performs an analysis to determine the traffic on the clients.

[0038] As mentioned above, the method (400) includes determining (402) a priority level for each of the application tiers. As will be described in later parts of this specification, the method (400) focuses on an application tier with the highest priority level to determine if the application tier is to be scaled up or scaled down.

[0039] In one example, determining the priority level for each of the application tiers includes determining a number of dependencies for each of the application tiers to other different application tiers. For example, if a login service serves a web Ul tier, a business logic tier, and a security tier, the method (400) determines the priority level is three.

[0040] In another example, determining the priority level for each of the application tiers includes determining the priority level set by an application owner. In this example, the priority level for each of the application ties may be set by the application owner via a Ul. For example, the Ul allows the application owner to specify a priority level for each of the application tiers. The Ul may include text boxes, pull down boxes, among other methods to allow the user to specify the priority level for each of the application tiers.

[0041] As mentioned above, the method (400) includes identifying (403), based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers. According to the analysis of the real user monitoring, the method (400) understands which application tiers suffer from issues such as delays issues, performance issues, and availability issue. This may be accomplished according to baseline and even according to static thresholds.

[0042] As mentioned above, the method (400) includes scaling (404), according to a scaling plan, the application tiers based on the issues and the priority level for each of the application tiers. In one example, scaling, according to the scaling plan, the application tiers based on the issues and the priority level for each of the application tiers includes scaling up or scaling down.

[0043] In one example, scaling up includes identifying the issues for the application tiers that are due to a heavy traffic load from users. In this example, the heavy traffic load from users may slow down the application tier thus causing issues.

[0044] Scaling up further includes selecting a single application tier from the application tiers that have the issues due to the heavy traffic load from the users. For example, if a web tier and a database tier both suffer from poor performance it may very well be that scaling the database tier will resolve both issues. As a result, the method (400) scales the database tier.

[0045] Further, scaling up includes scaling the single application tier according to the scaling plan. In one example, the scaling plan may be as simple as adding identical servers to the application tier. In another example, the scaling plan may be complex. For example, the scaling plan may first attempt to add more CPU cores, RAM, and memory to the servers. Next, the scaling plan may increase usage patterns of cache services. Finally, the scaling plan may add more servers.

[0046] Scaling up further includes revaluating the application tiers to identify further issues for the application tiers. In one example, selecting a single application tier from the application tiers that have issues due to the heavy traffic load from the users and remediating that issue may or may not fix the issues or may result in further issues. As a result, the method (400) revaluates the application tiers to identify further issues for the application tiers. If there are further issues, the scaling up method repeats. Alternatively, if there are no further issues, the scaling method ends.

[0047] As mentioned above, scaling, according to the scaling plan, the application tiers based on the issues and the priority level for each of the application tiers includes scaling down. For example, in the case that no application tiers are suffering from issues, the method (400) scales down to use fewer resources. In one example, according to the highest priority level, the method (400) learns from the history of monitoring each of the application tiers and deduces whether to scale down.

[0048] For example, five different web servers, belong to web tiers, may handle a peak period of 500 MBPS from 10000 concurrent users. If the entire web tier is currently handling 10 KBPS from 100 concurrent users it should be clear that the method (400) could scale down and use fewer resources.

[0049] In one example, such an attempt to scale down may be done according to a traffic amount per second that application tiers are handling. In another example, such an attempt to scale down may be done based on the number of user tiers the servers are handling. In yet another example, such an attempt to scale down may be done according to a factor ratio. In one example, the factor ratio may be provided by application owner. In another example, the factor ratio may be calculated dynamically by a learning function.

[0050] In one example, the method (400) scales down by Identifying, based on the priority level, a single application tier that can handle a heavier traffic load. If an application tier can handle a heavier traffic load, the application tier may be underutilized.

[0051] The method (400) scales down by determining if the single application tier passes a ratio factor test. As mentioned above, the factor ratio may be provided by application owner. Further, the factor ratio may be calculated dynamically by a learning function. For example, when reducing from 500 megabits per second (Mbps) to 10 kilobits per second (Kbps), the ratio may be 50,000:1. In one example, to scale down, the ratio factor has to be greater than 500:1. In one example, if the ratio factor test passes, the method (700) may continue. Alternatively, if the ratio factor test fails, the method (700) may not continue.

[0052] The method (400) further scales down by scaling the single application tier according to the scaling plan. As mentioned above, the scaling plan may be simple or complex.

[0053] The method (400) scales down by revaluating the application tiers to identify further issues for the application tiers. In one example, selecting a single application tier from the application tiers to scale down may lead to issues. As a result, the method (400) revaluates the application tiers to identify further issues for the application tiers. If there are further issues, the scaling down method repeats. Alternatively, if there are no further issues, the scaling down method ends.

[0054] Fig. 5 is a flowchart of an example of a method for optimizing scaling based on real user experience, according to one example of principles described herein. In one example, the method (500) may be executed by the system (100) of Fig. 1. In other examples, the method (500) may be executed by other systems such as system 600 or system 700. In this example, the method (500) includes monitoring (501), using a real user monitor solution, application tiers, determining (502) a priority level for each of the application tiers, identifying (503), based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers, obtaining (504) a scaling plan, in which the scaling plan determines how to scale the application tiers, and scaling (505), according to the scaling plan, the application tiers based on the issues and the priority level for each of the application tiers.

[0055] As mentioned above, the method (500) includes obtaining (504) a scaling plan, in which the scaling plan determines how to scale the application tiers. In one example, the scaling plan may as simple as adding identical servers to the application tier. In another example, the scaling plan may be complex. For example, the scaling plan may first attempt to add more CPU cores, RAM, and memory to the servers. Next, the scaling plan may increase usage patterns of cache services. Finally, the scaling plan may add more servers.

[0056] In one example, a Ul may allow a user to define the scaling plan. By defining the scaling plan, the scaling system of Fig. 1 may obtain the scaling plan. Further, other methods and techniques may be used to define the scaling plan.

[0057] Fig. 6 is a diagram of an example of an optimizing system (600), according to one example of principles described herein. The optimizing system (600) includes a monitoring engine (602), a determining engine (604), an identifying engine (606), and a scaling engine (608). In this example, the optimizing system (600) also includes an obtaining engine (610). The engines (602, 604, 606, 608, 610) refer to a combination of hardware and program instructions to perform a designated function. Each of the engines (602, 604, 606, 608, 610) may include a processor and memory. The program instructions are stored in the memory and cause the processor to execute the designated function of the engine.

[0058] The monitoring engine (602) monitors, using a real user monitor solution, application tiers. In one example, the monitoring engine (602) monitors the application tiers using a sniffer based solution, a server agent code injection solution, a client instrumentation solution, or combinations thereof.

[0059] The determining engine (604) determines a priority level for each of the application tiers. In one example, the determining engine (604) determines the priority level for each of the application tiers by determining a number of dependencies for each of the application tiers, determining the priority level set by an application owner, or combinations thereof.

[0060] The identifying engine (606) identifies, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers. In one example, the identifying engine (606) identifies one issue associated with each of the application tiers. In another example, the identifying engine (606) identifies several issues associated with each of the application tiers.

[0061] The scaling engine (608) scales, according to a scaling plan, the application tiers based on the issues and the priority level for each of the application tiers. In one example, the scaling engine (608) scales up or scales down.

[0062] In one example, the scaling engine (608) scales up by identifying the issues for the application tiers that are due to a heavy traffic load from users, selecting a single application tier from the application tiers that have the issues due to the heavy traffic load from the users, scaling the single application tier according to the scaling plan, and revaluating the application tiers to identify further issues for the application tiers.

[0063] In one example, the scaling engine (608) scales down by identifying, based on the priority level, a single application tier that can handle a heavier traffic load, determining if the single application tier passes a ratio factor test, scaling the single application tier according to the scaling plan, and revaluating the application tiers to identify further issues for the application tiers.

[0064] The obtaining engine (610) obtains the scaling plan, in which the scaling plan determines how to scale the application tiers. In one example, the obtaining engine (610) obtains one scaling plan. In another example, the obtaining engine (610) obtains several scaling plans.

[0065] Fig. 7 is a diagram of an example of an optimizing system (700), according to one example of principles described herein. In this example, optimizing system (700) includes processing resources (702) that are in communication with memory resources (704). Processing resources (702) include at least one processor and other resources used to process

programmed instructions. The memory resources (704) represent generally any memory capable of storing data such as programmed instructions or data structures used by the optimizing system (700). The programmed instructions shown stored in the memory resources (704) include an application tier monitor (706), a priority level determiner (708), an issue identifier (710), a scaling plan obtainer (712), and an application tier scaler (714).

[0066] The memory resources (704) include a computer readable storage medium that contains computer readable program code to cause tasks to be executed by the processing resources (702). The computer readable storage medium may be tangible and/or physical storage medium. The computer readable storage medium may be any appropriate storage medium that is not a transmission storage medium. A non-exhaustive list of computer readable storage medium types includes non-volatile memory, volatile memory, random access memory, write only memory, flash memory, electrically erasable program read only memory, or types of memory, or combinations thereof.

[0067] The application tier monitor (706) represents programmed instructions that, when executed, cause the processing resources (702) to monitor, using a real user monitor solution, application tiers. The priority level determiner (708) represents programmed instructions that, when executed, cause the processing resources (702) to determine a priority level for each of the application tiers.

[0068] The issue identifier (710) represents programmed instructions that, when executed, cause the processing resources (702) to identify, based on monitoring the application tiers, issues associated with each of the application tiers, the issues representing current states of the application tiers, as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers. The scaling plan obtainer (712) represents programmed instructions that, when executed, cause the processing resources (702) to obtain a scaling plan, in which the scaling plan determines how to scale the application tiers. The application tier scaler (714) represents programmed instructions that, when executed, cause the processing resources (702) to scale, according to the scaling plan, the application tiers based on the issues and the priority level for each of the application tiers.

[0069] Further, the memory resources (704) may be part of an installation package. In response to installing the installation package, the programmed instructions of the memory resources (704) may be downloaded from the installation package's source, such as a portable medium, a server, a remote network location, another location, or combinations thereof. Portable memory media that are compatible with the principles described herein include DVDs, CDs, flash memory, portable disks, magnetic disks, optical disks, other forms of portable memory, or combinations thereof. In other examples, the program instructions are already installed. Here, the memory resources can include integrated memory such as a hard drive, a solid state hard drive, or the like.

[0070] In some examples, the processing resources (702) and the memory resources (702) are located within the same physical component, such as a server, or a network component. The memory resources (704) may be part of the physical component's main memory, caches, registers, non-volatile memory, or elsewhere in the physical component's memory hierarchy.

Alternatively, the memory resources (704) may be in communication with the processing resources (702) over a network. Further, the data structures, such as the libraries, may be accessed from a remote location over a network connection while the programmed instructions are located locally. Thus, the optimizing system (700) may be implemented on a user device, on a server, on a collection of servers, or combinations thereof.

[0071] The optimizing system (700) of Fig. 7 may be part of a general purpose computer. However, in alternative examples, the optimizing system (700) is part of an application specific integrated circuit.

[0072] The preceding description has been presented to illustrate and describe examples of the principles described. This description is not intended to be exhaustive or to limit these principles to any precise form disclosed. Many modifications and variations are possible in light of the above teaching.

Claims

OPTIMIZING SCALING BASED ON REAL USER EXPERIENCE

BACKGROUND

BRIEF DESCRIPTION OF THE DRAWINGS

DETAILED DESCRIPTION

[0019] In one example, the system (100) includes a user device ( 12) with a display (110). In this example, a user device (112) may be used by a user to access applications (112) over a network (106). As will be described in other parts of this specification, the application tiers (114) may be layers of functionality for applications (112). Further, the applications (112) may use the resources (108) when accessing or processing data. In one example, a resource may be a server, a database, RAM, CPU, other resources, or combinations thereof. The more users that access the applications (112), the heavier the traffic load on the network (106). In one example, if the traffic load on the network (106) is excessive, this may cause issues such as performance issues, availability issues, delay issues, other issues, or combinations thereof for the application tiers (114).

[0020] The system (100) further includes an optimizing system (110). As will be described in other parts of this specification, the optimizing system (110) monitors, using a real user monitor solution, application tiers (114). In one example, the optimizing system (110) monitors all incoming and outgoing traffic to every application tier (114) and based on that measurement, the optimizing system (110) deduces and calculates performance and availability of the application tiers (114).

[0022] The optimizing system (110) further identifies, based on monitoring the application tiers (114), issues associated with each of the application tiers (114), the issues representing current states of the application tiers (114), as monitored by the real user monitor solution, in which the current states indicate negative impacts on the application tiers (114). In one example, an issue may be a performance issue, an availability issue, a delay issue, other issues, or combinations thereof for the application tiers (114).

[0023] Further, the optimizing system (110) scales, according to a scaling plan, the application tiers (114) based on the issues and the priority level for each of the application tiers (114). Such a method allows scaling of the