Abstract: Periodicity similarity between two different tracer objectives may be used to identify additional input parameters to sample. The tracer objectives may be individual portions of a large tracer operation, and each of the tracer objectives may have separate set of input objects for which data may be collected. After collecting data for a tracer objective, other tracer objectives with similar periodicities may be identified. The input objects from the other tracer objectives may be added to a tracer objective and the tracer objective may be executed to determine a statistical significance of the newly added objective. An iterative process may traverse multiple input objects until exhausting possible input objects and a statistically significant set of input objects are identified.

Abstract: An event chain visualization of performance data may show the execution of monitored elements as bars on a timeline, with connections or other relationships connecting the various bars into a sequential view of an application. The visualization may include color, shading, or other highlighting to show resource utilization or performance metrics. The visualization may be generated by monitoring many events processed by an application, where each bar on a timeline may reflect multiple instances of a monitored element and, in some case, the aggregated performance.

Abstract: A visualization system for a tracer may include a processing pipeline that may generate tracing data, preprocess the data, and visualize the data. The preprocessing step may include a mechanism to process user-defined expressions or other executable code. The executable code may perform various functions including mathematical, statistical, aggregation with other data, and others. The preprocessor may perform malware analysis, test the functionality, then implement the executable code. A user may be presented with an editor or other text based user interface component to enter and edit the executable code. The executable code may be saved and later recalled as a selectable transformation for use with other data streams.

Abstract: An event chain visualization of performance data may show the execution of monitored elements as bars on a timeline, with connections or other relationships connecting the various bars into a sequential view of an application. The visualization may include color, shading, or other highlighting to show resource utilization or performance metrics. The visualization may be generated by monitoring many events processed by an application, where each bar on a timeline may reflect multiple instances of a monitored element and, in some case, the aggregated performance.

Abstract: A parallel tracer may perform detailed or heavily instrumented analysis of an application in parallel with a performance or lightly instrumented version of the application. Both versions of the application may operate on the same input stream, but with the heavily instrumented version having different performance results than the lightly instrumented version. The tracing results may be used for various analyses, including optimization and debugging.

Abstract: A tracing management system may use cost analyses and performance budgets to dispatch tracing objectives to instrumented systems that may collect trace data while running an application. The tracing management system may analyze individual tracing workloads for processing, storage, and network performance costs, and select workloads to deploy based on a resource budget that may be set for a particular device. In some cases, complementary tracing objectives may be selected that maximize consumption of resources within an allocated budget. The budgets may allocate certain resources for tracing, which may be a mechanism to limit any adverse effects from tracing when running an application.

Abstract: A force directed graph may display time series data using a set of playback controls to pause, play, reverse, fast forward, slow down, or otherwise control the display of the time series data. The playback controls may be used in a real time or near real time application to which data sets are displayed and the speed with which the data sets may be displayed. In one architecture, the force directed graph may be deployed using a rendering engine that receives data and renders the data into a graph. A playback controller may send updates to the rendering engine according to user inputs from the playback controls.

Abstract: Periodicity similarity between two different tracer objectives may be used to identify additional input parameters to sample. The tracer objectives may be individual portions of a large tracer operation, and each of the tracer objectives may have separate set of input objects for which data may be collected. After collecting data for a tracer objective, other tracer objectives with similar periodicities may be identified. The input objects from the other tracer objectives may be added to a tracer objective and the tracer objective may be executed to determine a statistical significance of the newly added objective. An iterative process may traverse multiple input objects until exhausting possible input objects and a statistically significant set of input objects are identified.

Abstract: A module-specific tracing mechanism may trace the usage of a module on behalf of the module developer. The module may be used by multiple application developers, and the tracing system may collect and summarize data for the module in each of the different applications. The data may include usage data as well as performance data. Usage data may include anonymized data for each time the module may be invoked and called, and performance data may include the processing time, memory consumption, and other metrics. The module-specific tracing may be enabled or disabled by an application developer.

Abstract: Input sequence information may be analyzed and quantified using n-gram analysis of inputs received by an application. The sequences of inputs may be represented by n-grams, and the frequency of the various n-grams may indicate the ‘real world’ uses of the application in production, which may be compared to a test suite whose coverage may be quantified using a similar n-gram analysis. A coverage factor may compare the observed inputs to the application in production to the test suite for the application. The n-grams may be further quantified or prioritized by resource utilization and several visualizations may be generated from the data.

Abstract: A behavior model for a software application may identify a set of execution sequences that begin from a set of origins. The sequences may be further defined by a set of exits. In some cases, the sequences may be decomposed into subsequences or n-grams. The execution sequences and their frequencies may define a usage or behavior model for the application. The sequences may be defined by semantic level operations of an application, which may be defined by functions, call backs, API calls, or other blocks of code execution. The behavior model may be used for determining code coverage, comparing versions of applications, and other uses.

Abstract: Comparisons of different versions of an application may be compared using a behavior model of the application. A behavior model may be derived from n-gram analysis of observations of the application in production. The behavior model may include sequences of inputs received by the application or functions performed by the application, where each sequence is an n-gram observed in tracer data. Each n-gram may be coupled with a resource consumption to give a behavior model with performance data. A regression analysis may apply a behavior model derived from a first version of an application to the performance observations of a new version to create an expected performance metric for the new version. A similarly calculated metric from a previous version may be compared to the metric from a new version to determine an improvement or degradation of performance.

Abstract: Execution sequence information may be analyzed and quantified using n-gram analysis of functions executed by an application. The sequences of functions may be represented by n-grams, and the frequency of the various n-grams may indicate the behavior of the application in production, which may be compared to a test suite whose coverage may be quantified using a similar n-gram analysis. A coverage factor may compare the observed behavior of the application in production to the test suite for the application. The n-grams may be further quantified or prioritized by resource utilization, and several visualizations may be generated from the data.

Abstract: Regression testing of an application may gather performance tests for multiple functions within an application and determine when performance changes from one version of the application to another. The analysis may be further broken down by input sequences that may be processed by various functions. A detailed regression analysis may be presented as a heat map or other visualizations. A regression testing system may be launched during a build process by automatically launching a set of performance tests against an application. In many cases, the application may be executed in a system with a known or consistent performance capabilities. The application may be executed and tested in a new version and at least one prior version on the same hardware and software execution environment, so that results may be normalized from one execution run to another. A regression testing system may be deployed as a paid-for service that may integrate into a source code repository.

Abstract: N-grams of input streams or functions executed by an application may be analyzed to identify security breaches or other anomalous behavior. A histogram of n-grams representing sequences of executed functions or input streams may be generated through baseline testing or production use. An alerting system may compare real time n-gram observations to the histogram of n-grams to identify security breaches or other changes in application behavior that may be anomalous. An alert may be generated that identifies the anomalous behavior. The alerting system may be trained using known good datasets and may identify deviations as bad behavior. The alerting system may be trained using known bad datasets and may identify matching behavior as bad behavior.

Abstract: A load balanced system may incorporate instrumented systems within a group of managed devices and distribute workload among the devices to meet both load balancing and data collection. A workload distributor may communicate with and configure several managed devices, some of which may have instrumentation that may collect trace data for workload run on those devices. Authentication may be performed between the managed devices and the workload distributor to verify that the managed devices are able to receive the workloads and to verify the workloads prior to execution. The workload distributor may increase or decrease the amount of instrumentation in relation to the workload experienced at any given time.

Abstract: A tracer may obfuscate trace data such that the trace data may be used in an unsecure environment even though raw trace data may contain private, confidential, or other sensitive information. The tracer may obfuscate using irreversible or lossy hash functions, look up tables, or other mechanisms for certain raw trace data, rendering the obfuscated trace data acceptable for transmission, storage, and analysis. In the case of parameters passed to and from a function, trace data may be obfuscated as a group or as individual parameters. The obfuscated trace data may be transmitted to a remote server in some scenarios.

Abstract: A tracing system may divide trace objectives across multiple instances of an application, then deploy the objectives to be traced. The results of the various objectives may be aggregated into a detailed tracing representation of the application. The trace objectives may define specific functions, processes, memory objects, events, input parameters, or other subsets of tracing data that may be collected. The objectives may be deployed on separate instances of an application that may be running on different devices. In some cases, the objectives may be deployed at different time intervals. The trace objectives may be lightweight, relatively non-intrusive tracing workloads that, when results are aggregated, may provide a holistic view of an application's performance.

Abstract: Periodicity similarity between two different tracer objectives may be used to identify additional input parameters to sample. The tracer objectives may be individual portions of a large tracer operation, and each of the tracer objectives may have separate set of input objects for which data may be collected. After collecting data for a tracer objective, other tracer objectives with similar periodicities may be identified. The input objects from the other tracer objectives may be added to a tracer objective and the tracer objective may be executed to determine a statistical significance of the newly added objective. An iterative process may traverse multiple input objects until exhausting possible input objects and a statistically significant set of input objects are identified.

Abstract: An analysis system may perform network analysis on data gathered from an executing application. The analysis system may identify relationships between code elements and use tracer data to quantify and classify various code elements. In some cases, the analysis system may operate with only data gathered while tracing an application, while other cases may combine static analysis data with tracing data. The network analysis may identify groups of related code elements through cluster analysis, as well as identify bottlenecks from one to many and many to one relationships. The analysis system may generate visualizations showing the interconnections or relationships within the executing code, along with highlighted elements that may be limiting performance.