Can Wire Data Be APM?
I recently read something – a blog, a tweet, a LinkedIn article perhaps –
describing the use of wire data to analyze application performance. I
remember that the author’s use of the term “APM” in this context caused
one reader to comment, complaining that “you can’t call wire data APM.”
This was around the same time I referred casually to Dynatrace’s wire data
offering (Data Center Real User Monitoring, or DC RUM) as both “APM for IT
Operations” and “probe-based APM.” So that complaint has stuck with me,
prompting me to ask – and offer an answer to – the question.
It depends, of course, on answers to related questions. How do you define
APM? What role does APM play in your organization? What APM insights can wire
data provide? Let’s take a brief look at each of these.
What is APM to you?
In very general terms (Wikipedia is great for this), APM ... (more)
In Part 6, we dove into the Nagle algorithm - perhaps (or hopefully)
something you'll never see. In Part VII, we get back to "pure" network and
TCP roots as we examine how the TCP receive window interacts with WAN links.
TCP Window Size
Each node participating in a TCP connection advertises its available buffer
space using the TCP window size field. This value identifies the maximum
amount of data a sender can transmit without receiving a window update via a
TCP acknowledgement; in other words, this is the maximum number of "bytes in
flight" - bytes that have been sent, are traver... (more)
When we think of application performance problems that are network-related,
we often immediately think of bandwidth and congestion as likely culprits;
faster speeds and less traffic will solve everything, right? This is
reminiscent of recent ISP wars; which is better, DSL or cable modems? Cable
modem proponents touted the higher bandwidth while DSL proponents warned of
the dangers of sharing the network with your potentially bandwidth-hogging
neighbors. In this blog entry, we'll examine these two closely-related
constraints, beginning the series of performance analyses using the ... (more)
In Part V, we discussed processing delays caused by "slow" client and server
nodes. In Part VI, we'll discuss the Nagle algorithm, a behavior that can
have a devastating impact on performance and, in many ways, appear to be a
Common TCP ACK Timing
Beyond being important for (reasonably) accurate packet flow diagrams,
understanding "normal" TCP ACK timing can help in the effective diagnosis of
certain types of performance problems. These include those introduced by the
Nagle algorithm, which we will discuss here, and application windowing, to be
discussed in Par... (more)
As a network professional, one of your newer roles is likely troubleshooting
poor application performance. For most of us, our jobs have advanced beyond
network "health," towards sharing - if not owning - responsibility for
application delivery. There are many reasons for this more justifiable than
the adage that the network is first to be blamed for performance problems.
(Your application and system peers feel they are first to be blamed as well.)
Two related influencing trends come to mind:
Increased globalization, coupled with (in fact facilitated by) inexpensive
bandwidth me... (more)