Abstract: A system, methods, and apparatus are provided for performing capacity planning within a system that experiences high volumes of data having high velocity and high variability. Based on historical traffic, a forecast is generated for one or more relatively coarse time periods (e.g., weeks, days), and is decomposed to yield finer-grained forecasts (e.g., for hours, minutes) by applying a distribution index also generated from historical traffic. Estimated replication latency for the forecast period can be calculated from the traffic forecast and an expected level of replication capacity. Further, a required amount of replication capacity can be determined based on a traffic forecast and a maximum replication latency permitted by a service level agreement (SLA) of an event consumer. In addition, replication headroom can be computed, to identify a maximum level of traffic that can be sustained without violating an SLA and/or a date/time at which a violation may occur.

Abstract: A system, apparatus, and methods are provided for dynamically adjusting or modifying the operating frequency of a CPU or other processor component, based on a current performance of an application (or applications) executed by the CPU and a target performance, such as a performance level identified in a service level agreement (SLA) associated with the application(s). Multiple thresholds or zones of performance are defined, which may be altered during operation (e.g., based on a profile or predicted CPU workload), and each threshold/zone is associated with a frequency adjustment to implement when the application's performance triggers the threshold or zone. Illustrative adjustments include maximizing the operating frequency, minimizing it, and scaling it up or down one or more discrete levels within a range of frequencies at which the CPU can operate. Thus, CPU operation is adjusted with a primary goal of satisfying application SLAs and a secondary goal of conserving energy.

Abstract: A system, methods and apparatus are provided for determining the locus of a bottleneck in a data transfer between a data receiver (e.g., a client device) and a data sender (e.g., a computer server). The locus may be one of a receiver realm encompassing the data receiver (especially a receiver application that consumes the data), a sender realm encompassing the data sender (especially a sender application that produces the data), and a communication link realm that encompasses the communication link(s) over which the data are conveyed (and possibly network-layer protocols and lower that use the communication link(s)). A monitor entity may employ a state-machine model to represent and track progress of a given data transfer between states, using information collected from the data receiver and data sender to identify state transitions. Given a time at which a transfer was delayed or halted, the monitor outputs the locus of the problem.