Telephone: (215) 716-7373

Home » Application & NetAnalysis » Interpath Application Flow Diagrams-01

Interpath Application Flow Diagrams-01

Bookmark and Share

Interpath Application Flow Diagramming has been the second most frequently read or listened to topic on the Interpath Technologies website and The Sniffer Guy / The ROOT Cause podcast series.  While it has been discussed in previous articles and podcasts, I felt it warranted some more attention.  It is also the most frequent request we receive in emails.  People are looking for templates.  In response, we are creating a list of templates but it is a difficult process because each situation is unique.  That being said, there are many similarities and common mistakes.  

An Interpath Diagram (application flow diagram or process flow diagram) is NOT a network diagram, although there are similarities.  When I ask for this type of diagram, nine out of ten times, what I receive is a Network Diagram.  Let’s discuss the differences.

Interpath Application Flow Diagram

  • Contains Layer 4 Port (TCP or other) information.
  • Shows what IP addresses communicate with what other IP addresses and what protocols they use to do so.
  • Is very concerned with “Tier” information.  How does a message get from source to destination?
  • Contains IP addresses—both actual and virtual, including all physical interfaces on the box.

Network Diagram

  • Shows infrastructure such as Routers and Switches.  (This may also be needed as supplemental information for the project, but is not a typical part of the Interpath Application Flow Diagram.)
  • Shows routing information.
  • Contains IP addresses—both actual and virtual, including all physical interfaces on the box. (An area of overlap with the Interpath Application Flow Diagram.)

The focus is entirely different.  The Network Diagram is concerned with how data moves from one subnet to another while the Interpath Application Flow Diagram is focused on how data moves between the source computer and the destination computer—to the next destination computer—to the next destination computer, and how long each computer takes to perform its job. It is more about tiers than switches.

These are the goals of the Interpath Application Flow Diagram:

To allow for the creation of Transactional Test “Click Streams” that can be used to show test users exactly what actions to perform during a test session.

To guide the Test Designer in where to place the physical Packet-Sniffers (e.g. Wireshark) in the infrastructure.  Since the Network Application Performance Analyst (NAPA™) is not going to be the one to create the port mirrors (SPANs) or place the packet-sniffers themselves--knowing the Network in great detail is not necessary.  What is critical is being able to know from a transactional flow, what IP addresses need to be monitored. The Interpath Application Flow Diagram is able to provide that level of detail.  This way, the Network Application Performance Analyst (NAPA™)can inform the Network Engineer, who will be doing the Port Mirroring (SPANing), where visibility is needed--depending on what part of the transaction needs to be seen and is being tested.

A template for a clear and simple Interpath Application Flow Diagram can be seen below

One major area of confusion is with IP addresses.  Odd as it may seem, if you really ask, you may find that the IP addresses are not known for the various component servers.  There are Physical Interface IP addresses, Virtual IP addresses, Production IP address, Management IP addresses and IP addresses for different applications or database instances.  It is very likely that no one knows them all.  Similarly, it there is usually no planning of TCP port designation.  In some cases, a team may select a TCP port for an application that is actually be a port that is commonly (if not formally) used for another application, thereby confusing packet-sniffers and other monitors.  All of this must be clearly stated in an Interpath Application Flow Diagram.

Related Topics:

Back to main topic: Application & NetAnalysis
The Application's Interpath
Network & Application Performance Analysis Fundamentals
Building a Simple Open-Source Distributed Packet-Sniffer
Performance Tuning Is A Process -- Not A Tool
Excessive TCP Connections
Why Network Assessments Must Include Application Behavior
The 7 Most Common Mistakes Using Packet-Sniffers
Packet-Sniffer Filtering Concepts-01
Baselining--Stress Testing--Performance Testing--Oh My--Part ONE
Baselining--Stress Testing--Performance Testing--Oh My--Part TWO
The Saturation Point
Multi-Tier Latency Concepts-01
Application Profiling Concepts - Part One

Subscribe to receive the latest news & specials on our products:

Quick Find
Use keywords to find the product you are looking for.
Advanced Search

New Articles
All Topics
 Application & NetAnalysis
 Case Studies .
 NetAnalysis Myth Series
 Team Building
Articles RSS Feed
Shipping & Returns
Privacy Notice
Conditions of Use
Contact Us
Catalog Feed

Copyright © 1999-2013 Barry Koplowitz