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.
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.
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.
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