From the Blogosphere
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
By: Gary Kaiser
Mar. 18, 2016 03:15 AM
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
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:
Application Performance Analytics: Foundation & Key Insights
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:
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.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week