Gary Kaiser

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

Top Stories by Gary Kaiser

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. Server Processing (Between Flows) From the network's perspective, we allocate the time period between the end of a request flow and the beginning of the corresponding reply flow to server processing. Generally speaking, the server doesn't begin processing a request until it has received the entire flow, i.e., the last packet in the request message; similarly, the server doesn't begin sending the reply until it has finished processing the request. We sometimes refer to these delays between flows as "pure" processing delays, distinct from another type of intra-flow processing delay we call starved for data and discuss later. Server processing delays ... (more)

IT Operations and Digital Disruption | @DevOps Summit #APM #DevOps

Transaction-Centric NPM: Enabling IT/Business Collaboration 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 users, and effective communication requires a clear understanding of their experience with the application services you deliver. But how well do you understand end-user experience? To answer that question, let's first define end-user experie... (more)

Understanding Application Performance on the Network | Part 1

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)

Understanding Application Performance on the Network | Part 4

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 performance analysis perspective, how do you understand the relevance of packet loss and avoid chasing red herrings? In Part II, we examined two closely related constraints - bandwidth and congestion. In Part III, we discussed TCP slow-start and introduced the Congestion Window (CWD). In Part IV, we'... (more)

Transaction-Centric NPM | @CloudExpo #APM #DevOps #Microservices

Transaction-Centric NPM: Enabling IT Operations/Development Collaboration 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 background on the importance of understanding exactly how we define response time, since this definition dictates the usefulness of the measurement. For the sake of brevity, I'll summarize three common definitions here: Session-la... (more)