Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Question about Thread Analysis


Thread Analysis:

I have a basic question on the Thread Analysis:

DNA provides a TCP connection as a combination of client IP, client port, server IP and server port. For this TCP connection DNA starts then the decoding of the traffic.

DNA checks the server port number to determine which Decode is used to decode the traffic.

On the basis of the protocol as HTTP, it is on every HTTP request to create a thread based. This means over a TCP connection may result in multiple threads

In the accompanying screenshot shows some threads with the same client port so I'm assuming that DNA, for example, for HTTP traffic, the various HTTP requests recognizes.

thread analysis_algorithmus_http.jpg

thread analysis_algorithmus_TNS.jpg

But I would like to know exactly what algorithmic DNA of the different requests with the same client port resumes to a thread?



Hi Sandra,

The answer lies within the thread decodes themselves.

DNA’s protocol identification actually uses pattern-matching, relying on the port number as a last resort. Based on the identified protocol, DNA then decodes the request and response exchanges between client and server, grouping these into logical threads. In many cases – HTTP is a good example – each thread has one request message (GET, POST, etc.) and one corresponding reply message (HTTP 200, etc.). (BTW, this is counted as an application turn.) In some cases – Oracle is a good example – there may be many request/reply exchanges. The client may issue a Prepare&Execute request with a SELECT query; this becomes the thread name or label, as it is meaningful to the developer/DBA. Within this thread, the client may send many FETCH requests for the result records; these request/response pairs are not very meaningful to the DBA, although their application turns contribute to the chattiness of the thread.

In a more abstract definition, most protocols operate serially within a TCP connection; therefore, each request/reply exchange is simply a sequential collection of packet payload. Some protocols – HTTP in particular – may pipeline requests within a single TCP connection, issuing requests in parallel; each individual decode algorithm is responsible for understanding the protocol’s behavior and assembling packets into meaningful threads.

Here is a diagram of message request and responses at an abstract or application level:


And here is  more detail for a single request/reply exchange; the decode decides how to identify the thread, often (but not always) from the payload in the first packet or first few packets:


Note that these diagrams also begin to explain the Node Processing and Node Sending measurements as well.