Welcome!

Gary Kaiser

Subscribe to Gary Kaiser: eMailAlertsEmail Alerts
Get Gary Kaiser via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Latest Articles from Gary Kaiser
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....
In my last post, I wrote about the value of IT / business collaboration, and the importance of a common language, a common definition of end-user experience – user transaction response time – as the one performance metric both IT and business have in common. In it, I provided some back...
One of the consequences of digital disruption is that IT is propelled much closer to users, who expect applications and services to be available and to perform well anytime, anywhere, on any device. Communicating with the business now more than ever requires communicating with these us...
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. Each node participating in a TCP connection advertises its avail...
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 processing delay. Beyond being important for (reasonably) a...
In Part IV, we wrapped up our discussions on bandwidth, congestion and packet loss. In Part V, we examine the four types of processing delays visible on the network, using the request/reply paradigm we outlined in Part I. From the network’s perspective, we allocate the time period bet...
We know that losing packets is not a good thing; retransmissions cause delays. We also know that TCP ensures reliable data delivery, masking the impact of packet loss. So why are some applications seemingly unaffected by the same packet loss rate that seems to cripple others? From a pe...
In Part II, we discussed performance constraints caused by both bandwidth and congestion. Purposely omitted was a discussion about packet loss – which is often an inevitable result of heavy network congestion. I’ll use this blog entry on TCP slow-start to introduce the Congestion Windo...
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 mode...
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 jus...