Abstract: Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result.

Abstract: Techniques for monitoring web application performance are provided. A request for a web application is received at an application server. A response pipeline at the application server generates client application code corresponding to the requested web application. The client application code is intercepted in the response pipeline. Instrumentation code is inserted into the intercepted client application code to generate an instrumented client application code. The instrumentation code is configured to be executed when the instrumented client application code is rendered at the client to capture performance information at the client, and is configured to transmit the captured performance information from the client.

Abstract: A data service may be distributed over a set of servers in order to provide a database with properties such as low latency, high availability, and support for various consistency levels. Presented herein is a particular architecture that promotes rapid provisioning to promote scalability and failover; adaptive load-balancing to accommodate fluctuations in demand; and resiliency in the event of various types of failure, such as network partitions or regional outages. For a service comprising a resource set, a container is provided that hosts a set of replicas of a partition, and that is assigned an allocation of computing capabilities of one or more servers. The resource set of the service may be distributed over the replicas of the container. Scalability is achieved by adding replicas to the container, and load-balancing may be provided by splitting, merging, or otherwise refactoring the partition to accommodate anticipated and unanticipated fluctuations in service demand.

Abstract: Workloads are often performed by a server set according to a service level agreement, and are often provisioned and load-balanced by dedicating selected computational resources (e.g., servers and bandwidth) for application to the workload. However, resource-based provisioning may not accurately reflect the computational resource expenditure of the workload, leading to overprovisioning or underprovisioning of servers for the workload. Instead, the workload may be evaluated according to a service unit as a measurement of a volume of computational resources consumed by a workload unit, including performance dimensions specified in the service level agreement. The service level agreement may indicate a service unit rate for the workload. The workload may therefore be allocated to a subset of servers in portions according to a service unit rate, where the sum of the service unit rates for the portions allocated to the servers satisfies the service unit rate specified in the service level agreement.

Abstract: Processing services are often provisioned by defining and adjusting the performance capabilities of individual servers, and in multitenancy scenarios, servers may allocate computational resources to ensure that a first client workload does not impact a second client workload. However, a reduced performance capability of a server may create a processing jam with respect to an upstream server of the process path of the workload, where the processing rate mismatch creates a risk of failing to fulfill the performance guarantee for the workload. Instead, the downstream server may monitor and compare its performance capability with the performance guarantee. If a performance guarantee failure risk arises, the server may transmit a performance capability alert to the upstream server, which may rate-limit the processing of the workload. Rate-limiting by the first server in the server path may limit workload intake to a volume for which the process path can fulfill the performance guarantee.

Abstract: Workloads are often performed by a server set according to a service level agreement, and are often provisioned and load-balanced by dedicating selected computational resources (e.g., servers and bandwidth) for application to the workload. However, resource-based provisioning may not accurately reflect the computational resource expenditure of the workload, leading to overprovisioning or underprovisioning of servers for the workload. Instead, the workload may be evaluated according to a service unit as a measurement of a volume of computational resources consumed by a workload unit, including performance dimensions specified in the service level agreement. The service level agreement may indicate a service unit rate for the workload. The workload may therefore be allocated to a subset of servers in portions according to a service unit rate, where the sum of the service unit rates for the portions allocated to the servers satisfies the service unit rate specified in the service level agreement.

Abstract: Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result.

Abstract: A data service may be distributed over a set of servers in order to provide a database with properties such as low latency, high availability, and support for various consistency levels. Presented herein is a particular architecture that promotes rapid provisioning to promote scalability and failover; adaptive load-balancing to accommodate fluctuations in demand; and resiliency in the event of various types of failure, such as network partitions or regional outages. For a service comprising a resource set, a container is provided that hosts a set of replicas of a partition, and that is assigned an allocation of computing capabilities of one or more servers. The resource set of the service may be distributed over the replicas of the container. Scalability is achieved by adding replicas to the container, and load-balancing may be provided by splitting, merging, or otherwise refactoring the partition to accommodate anticipated and unanticipated fluctuations in service demand.

Abstract: Techniques for monitoring web application performance are provided. A request for a web application is received at an application server. A response pipeline at the application server generates client application code corresponding to the requested web application. The client application code is intercepted in the response pipeline. Instrumentation code is inserted into the intercepted client application code to generate an instrumented client application code. The instrumentation code is configured to be executed when the instrumented client application code is rendered at the client to capture performance information at the client, and is configured to transmit the captured performance information from the client.

Abstract: Techniques for monitoring web application performance are provided. A request for a web application is received at an application server. A response pipeline at the application server generates client application code corresponding to the requested web application. The client application code is intercepted in the response pipeline. Instrumentation code is inserted into the intercepted client application code to generate an instrumented client application code. The instrumentation code is configured to be executed when the instrumented client application code is rendered at the client to capture performance information at the client, and is configured to transmit the captured performance information from the client.

Abstract: Techniques for monitoring web application performance are provided. A request for a web application is received at an application server. A response pipeline at the application server generates client application code corresponding to the requested web application. The client application code is intercepted in the response pipeline. Instrumentation code is inserted into the intercepted client application code to generate an instrumented client application code. The instrumentation code is configured to be executed when the instrumented client application code is rendered at the client to capture performance information at the client, and is configured to transmit the captured performance information from the client.

Abstract: Techniques for monitoring web application performance are provided. A request for a web application is received at an application server. A response pipeline at the application server generates client application code corresponding to the requested web application. The client application code is intercepted in the response pipeline. Instrumentation code is inserted into the intercepted client application code to generate an instrumented client application code. The instrumentation code is configured to be executed when the instrumented client application code is rendered at the client to capture performance information at the client, and is configured to transmit the captured performance information from the client.

Abstract: Methods, systems, and computer-readable media are disclosed for monitoring a distributed application. A particular method identifies a plurality of components of a distributed application. The method also identifies a specific technology associated with a particular component and attaches a technology specific interceptor to the particular component based on the identified specific technology. The method includes intercepting messages that are sent by or received by the particular component using the technology specific interceptor. At least one potential work item is generated based on the intercepted messages. The method includes determining whether to schedule the at least one potential work item for execution based on a predicted impact of the at least one work potential item on performance of the distributed application.

Abstract: Techniques are described herein that are capable of monitoring activity with respect to a distributed application. A server system includes logical tiers, each including processing system(s) configured to process messages in accordance with a respective protocol (e.g., an ASP.net® protocol, WCF protocol, SQL protocol, etc.). When a user initiates an activity with respect to a distributed application, hops are performed between the logical tiers and/or between components of the distributed application to complete the requested activity. A hop is a transfer of a message or a procedure call from one processing system to another processing system. A common identifier may be assigned to each of the hops that are performed with regard to the activity. If a failure occurs with respect to the activity, the common identifier may be used to gather information regarding the hops. For instance, the information may be used to determine a source of the failure.

Abstract: Techniques for monitoring web application performance are provided. A request for a web application is received at an application server. A response pipeline at the application server generates client application code corresponding to the requested web application. The client application code is intercepted in the response pipeline. Instrumentation code is inserted into the intercepted client application code to generate an instrumented client application code. The instrumentation code is configured to be executed when the instrumented client application code is rendered at the client to capture performance information at the client, and is configured to transmit the captured performance information from the client.

Abstract: Techniques are described herein that are capable of monitoring activity with respect to a distributed application. A server system includes logical tiers, each including processing system(s) configured to process messages in accordance with a respective protocol (e.g., an ASP.net® protocol, WCF protocol, SQL protocol, etc.). When a user initiates an activity with respect to a distributed application, hops are performed between the logical tiers and/or between components of the distributed application to complete the requested activity. A hop is a transfer of a message or a procedure call from one processing system to another processing system. A common identifier may be assigned to each of the hops that are performed with regard to the activity. If a failure occurs with respect to the activity, the common identifier may be used to gather information regarding the hops. For instance, the information may be used to determine a source of the failure.

Abstract: Methods, systems, and computer-readable media are disclosed for monitoring a distributed application. A particular method identifies a plurality of components of a distributed application. The method also identifies a specific technology associated with a particular component and attaches a technology specific interceptor to the particular component based on the identified specific technology. The method includes intercepting messages that are sent by or received by the particular component using the technology specific interceptor. At least one potential work item is generated based on the intercepted messages. The method includes determining whether to schedule the at least one potential work item for execution based on a predicted impact of the at least one work potential item on performance of the distributed application.

Abstract: Methods, systems, and computer-readable media are disclosed for discovering components and dependencies in a distributed computing environment. A particular method includes discovering a first component and a second component of a distributed computing environment, where the first component and the second component are associated with different discoverable technologies. Each component is discovered based on a match between a characteristic of the component and a technology specification associated with the discoverable technology. The method also includes discovering a dependency between the first component and the second component.

Abstract: A system and method for monitoring processes corresponding to measurable values based on signatures associated with the measurable values is provided. The signatures can be created based on data from auxiliary data sets or auxiliary data sources. Additional monitoring information can be obtained by collecting dimensional data for the measurable values.

Abstract: A system and method for monitoring processes corresponding to measurable values based on signatures associated with the measurable values is provided. The signatures can be created based on data from auxiliary data sets or auxiliary data sources. Additional monitoring information can be obtained by collecting dimensional data for the measurable values.