Welcome!

@DevOpsSummit Authors: Destiny Bertucci, Pat Romanski, Yeshim Deniz, Dalibor Siroky, Liz McMillan

Related Topics: @DevOpsSummit, Microservices Expo, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Post

Application Performance Analytics | @DevOpsSummit @Dynatrace #DevOps #APM

How network and application metrics can be derived from a network probe, combined and analyzed to provide insights

Why a discussion around Application Performance Analytics? There's a lot of buzz in this industry around the topic of performance analytics - an informal subset of IT operations analytics (ITOA) - as a solution to the growing mountains of monitoring data and the increasing complexity of application and network architectures.

At the same time, there exist many purpose-built performance analysis solutions. Many are domain-centric - server monitoring and network monitoring, for example - while some exhibit a key ITOA characteristic by incorporating and correlating data from multiple sources. Most perform some level of analysis to expose predefined insights.

Application Performance Analytics: Viewed Through a Simple Framework
In this blog, I'll outline a simple analytics framework that illustrates how network and application metrics can be derived from a network probe ("wire data" to use the increasingly popular term), combined and analyzed to provide insights that are greater than the sum of the parts. (In fact, that is one of the core promises of ITOA.) I'll conclude by pointing out some of the more advanced analysis capabilities this framework might need to become a viable modern-day solution.

First, a bit of a disclaimer. My initial intent was to write about the new release of Dynatrace DC RUM; that was the assigned task. But I know if I started touting features - especially if I used ubiquitous (and usually meaningless) qualifiers such as "exciting, industry-leading, breakthrough, and best-of-breed," you'd probably stop reading. And rightly so; you don't come to this blog for product info, which is readily available here and here. (See what I did there?) Instead, I chose one of DC RUM's focus areas - advanced analytics - as an opportunity to wax technical; you can consider the framework a simplification and abstraction of one of the multiple approaches that DC RUM uses for automated fault domain isolation (FDI).

To keep this blog relatively simple, I'll use the example of a web page - although the framework would apply to any application that uses a request/reply paradigm; to be more universal, I'll switch terms slightly:

  • A transaction is the page load time that the user experiences
  • A hit is a component of the transaction -an image, stylesheet, JavaScript, JavaServer Page, etc.

Application Performance Analytics: Foundation & Key Insights
The Foundation: Hit Performance
Hit-level performance is the basic building block for the framework; it represents the smallest unit of measurement at the application layer, incorporating request and reply message flows as well as server processing delays. The measurement itself is quite straightforward; virtually any AA NPM probe would provide this (it's often referred to as session-layer response time), and the only decode requirement is to identify the TCP ports used. A hit begins with a client request message (PDU) that the client's TCP stack segments into packets for transfer across the network; this is observed by the probe as the request flow. A hit concludes with the server's reply message that is similarly segmented into packets for transfer across the network in the reply flow.

Often, the probe will sit near the application server, not the client, so a small adjustment should be made to the elapsed hit time observed at the server; add ½ of the network round-trip time (RTT) to the beginning and to the end of the measurement to arrive at a more accurate estimate of the performance at the client node. (RTT can be estimated by examining SYN/SYN/ACK handshakes - if they exist - or by more sophisticated ACK timing measurements.)

Timing diagram of a hit measurement

Allocating delays to client, network and server categories starts by calculating the duration of the request and reply flows. At this coarse level, we have a very simple network/server breakdown, but we'll need to apply additional analytics to make it useful. While it's a relatively safe assumption that the delay between the last packet of the client request flow and the first packet of the server reply flow should be allocated to server time, it is not appropriate to assume that the duration of the request and reply flows should be allocated to network time. Instead, when a flow's throughput is low, we should evaluate whether this is caused by the sender or the receiver before we blame the network. For example:

  • The receiver can limit throughput by advertising a TCP window size smaller than the MSS (frequently - and crudely - identified as Win0 events).
  • The sender may be the culprit if it can't deliver packets to the network fast enough; we sometimes refer to this as "sender starved for data."

We can consider the remaining flow duration as network time - still a pretty broad category. To further understand network time, we would want to evaluate for packet loss and retransmission as well as TCP receive window constraints in relationship to the BDP.

A more sophisticated analysis would include tests for additional less-common behaviors such as Nagle, application windowing, and TCP slow start; you can read detailed discussions on these and other network-visible performance bottlenecks by downloading the eBook Network Application Performance Analysis.

Click here for the full article.

More Stories By Gary Kaiser

Gary Kaiser is a Subject Matter Expert in Network Performance Analytics at Dynatrace, responsible for DC RUM’s technical marketing programs. He is a co-inventor of multiple performance analysis features, and continues to champion the value of network performance analytics. He is the author of Network Application Performance Analysis (WalrusInk, 2014).

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@DevOpsSummit Stories
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.
The need for greater agility and scalability necessitated the digital transformation in the form of following equation: monolithic to microservices to serverless architecture (FaaS). To keep up with the cut-throat competition, the organisations need to update their technology stack to make software development their differentiating factor. Thus microservices architecture emerged as a potential method to provide development teams with greater flexibility and other advantages, such as the ability to deliver applications at warp speed using infrastructure as a service (IaaS) and platform as a service (PaaS) environments.
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts. This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the public cloud best suits your organization, and what the future holds for operations and infrastructure engineers in a post-container world. Is a serverless world inevitable?