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

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

When to enable 'monitoring of persistent TCP sessions'???



I've got a basic question and looking to further my understanding of this setting.

When should and shouldn't this be checked?

My current understanding is that you enable this setting possibly on the backend (DB) tiers when there is a strong chance they are keeping the sessions pinned open and are using them for multiple purposes.

Any suggestions are welcome.




The persistent TCP sessions parameter allows the AMD to analyze sessions for which the beginning (handshake) was not seen, e.g. due to an AMD restart. It's especially useful for long sessions, like DB ones.

It has no effect on AMD HS, where all sessions are analyzed regardless whether the handshake was seen or not.


Thanks Wojciech!

By not seeing the handshake, does that affect our response time measures at all? Or metrics like RTT that I thought was measured on that initial 3-way handshake?

Yes, when the session is not analyzed from the beginning, the RTT metrics are not calculated. Whether it will affect operation times or not depends on the protocol and decode used - for example, MQ includes the RTT in operation time.

But then again, I could just use ACK RTT to get around that.

Good to know though! Thanks again.

So @Wojciech Kurek - are you saying that on an ordinary AMD - no analysis is done until we see a handshake, unless this check box is ticked (given a long bi node conversation)?

That's correct.

But other metrics must be calculate such the volume and number of end points?

Just saw this on a Citrix environment I was working with. User session was a 7 day session. We restarted AMD and session count was drastically lower because we didn't capture the handshake.

Yes -that's a well known effect. But did you check what happend if you had the persistent check box ticked?

Did it effect the user Count or not?

Dynatrace Pro
Dynatrace Pro

The description done by Wojceiech is true, when you have long connections, open, let's put some examples of this kind of connections:

- Heavy clients. Some heavy clients will open the connection with the server, and it will stay open till the heavy client ends.

- Batch processing, the batch can open long connections during the long duration of the batch, this includes the database ones.

- On backend protocols, you can find any kind of server that uses connections pools where the minimum connection pool size will stay open. Quite a lot seen on MQ and sometimes over Databases.

- Intra server communication protocols or control protocols (for example clustering protocols)

- File transfers protocols

Here some examples that I hope you find usefull.

Thanks David for tying to it on the ground examples.

So for standard web traffic, as long as it isn't fat client connecting to it... it really shouldn't be used.

yes normal HTTP browser will not use persistent conexions. There are Web servers configurations that allow to reuse connections to serve contents, but their life use not to be much longer to be considered persistent