A method for adjusting the resource allocation ratio between microservices used to run an application. A microservice test sequence is defined which has an order that follows the traffic flow through the microservices. Each microservice is analyzed in order of the test sequence to classify whether or not it is acting as a bottleneck for the application. This is done by measuring whether or not decrementing the microservice's resource causes the application throughput to decrease. For each microservice classified as a bottleneck and in reverse order of the test sequence, its resource is successively incremented until the application throughput starts to increase, indicating it is no longer acting as a bottleneck. The resource allocation ratio can then be adjusted to reflect this procedure.

This document describes a framework for measuring and improving the performance of applications, such as distributed applications and web applications. In one aspect, a method includes performing a test on an application. The test includes executing the application on one or more computers and, while executing the application, simulating a set of workload scenarios for which performance of the application is measured during the test. While performing the test, a set of performance metrics that indicate performance of individual components involved in executing the application during the test is obtained. A knowledge graph is queried using the set of performance metrics. The knowledge graph links the individual components to corresponding performance metrics and defines a set of hotspot conditions that are each based on one or more of the corresponding performance metrics for the individual components. A given hotspot condition is detected based on the set of performance metrics.

Embodiments of the present invention provide a system for leveraging distributed register technology to securely monitoring, tracking, and recommending utilization of resources. The system is configured for gathering one or more input parameters from one or more entity systems, collecting activity data from one or more third party systems, analyzing the activity data collected from the one or third party systems, generating one or more recommendations based on the one or more input parameters and analyzing the activity data, wherein the one or more recommendations are associated with one or more activities, estimating resource usage for the one or more recommendations, and allocating resources to the one or more recommendations.

A computer implemented method comprises receiving a request to provision a container as a software container on a current node of the cluster. The method further comprises accessing a performance information data store (PIDS) to obtain a record associated with the container that includes benchmarked performance metrics including container-required resources associated with a benchmark-specified node of the container. The method further comprises accessing the PIDS to obtain a record associated with the current node of the cluster that includes current-node performance metrics associated with the current node. The method further comprises comparing the benchmarked performance metrics with the current node performance metrics to determine that a difference exists, and conditioned upon the difference existing adjusting, with a resource adjustment calculator, the container-required resources based on the determination of how much of a difference exists. The method then provisions the container on the current node with adjusted container-required resources.

A stream of tuples is processed by a stream application. The stream application includes a plurality of processing elements that operate on one or more compute nodes, each processing element includes one or more stream operators. One or more databases that are capable of communicating with the stream application are monitored during the processing of the stream of tuples. A potential performance condition of a first database of the one or more databases is detected based on the monitoring. An output adjustment is performed, in response to the potential performance condition.

A method for adjusting the resource allocation ratio between microservices used to run an application. A microservice test sequence is defined which has an order that follows the traffic flow through the microservices. Each microservice is analyzed in order of the test sequence to classify whether or not it is acting as a bottleneck for the application. This is done by measuring whether or not decrementing the microservice's resource causes the application throughput to decrease. For each microservice classified as a bottleneck and in reverse order of the test sequence, its resource is successively incremented until the application throughput starts to increase, indicating it is no longer acting as a bottleneck. The resource allocation ratio can then be adjusted to reflect this procedure.

In general, embodiments of the invention relate to a method for generating upgrade recommendations. The method comprising obtaining telemetry data for a target entity, determining, using the telemetry data, at least one of a predicted upgrade time and a upgrade readiness factor for the target entity, generating an recommendation based on the at least one of the predicted upgrade time and the upgrade readiness factor for the target entity, and initiating a display of the recommendation on a graphical user interface of client.

A storage system includes a plurality of storage nodes. Each storage node of the plurality of storage nodes includes a plurality of non-volatile memory modules. The storage system also includes a processor operatively coupled to the plurality of storage nodes, to perform a method. The method includes receiving incoming data. The method further includes storing the incoming data in a redundant array of independent drives (RAID) stripe in the data storage system. The RAID stripe includes groups of data shards. Each group of data shards and a respective group parity shard are stored across the plurality of nodes of the data storage system. A set of stripe parity shards are stored in a first storage node of the plurality of storage nodes.

A capacity planning method for Always On Availability Group, AG, cluster renewal includes selecting a source AG cluster to be replaced with a target AG cluster, selecting at least one performance monitor and monitoring performance of instances and databases to obtain time series. Trends of the time series are defined and at least one benchmark value is obtained for source and target nodes and calculating at least one benchmark ratio. The time series are adjusted based on the defined trends and the at least one benchmark ratio. A logical grouping of instances and databases is constituted, and workloads of the logical groups are calculated for each node on basis of the adjusted time series. A required capacity of the target AG cluster nodes is predicted. Finally, the required capacity of the target AG cluster nodes is compared to verify, whether the target node has sufficient capacity.

Certain embodiments disclosed herein provide application-specific launch optimization. Aspects of the present disclosure include one or more cost functions for each application, where each cost function corresponds to a likelihood that a particular application should be placed into a particular pre-activation state. For each of the inactive applications, a respective one of the pre-activation states is selected based on comparing cost values obtained by evaluating the cost functions. Each of the inactive applications can be moved to or maintained in the respectively-selected pre-activation state to more efficiently provide an expedited application launch experience for a user.