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

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

Encrypted data exchange operation taking more response time

sponnada2
Organizer

hi All,

Encrypted data exchange taking high response time for one module.what could be reason for it.Is this because cert changes on Application side.Module contains *RSA*.


5 REPLIES 5

Krzysztof_Ziemi
Dynatrace Pro
Dynatrace Pro

First of all, looking at response time for encrypted data exchange wouldn't typically lead to meaningful conclusions. We don't know what data is transferred inside, so we can't tell what influenced response time. The biggest unknown is the response size: obviously larger responses (larger pages) will take longer time to transfer. Looking at response's realized bandwidth and network performance tells lots more.

Having said that, certificate change shouldn't have direct impact on the encrypted data exchange speed (measured by realized bandwidth and watching the network performance conditions to confirm they didn't change). Unless certificate change also caused a change in the symmetric ciphers that client and server negotiate for the data transfer. If this cipher changed, then it is possible that encryption/decryption takes more time. But potential differences here should be rather small.


sponnada2
Organizer

Some of the traffic is not being decrypted. Only about 2% of the
operations are not being decrypted, but these 2% are the ones with the highest
response time.

if we look at the traffic
diagnostics, most of the non-decrypted sessions are due to “Non Syn Sessions”.

What exactly it means and how can get to know the issu


When AMD doesn't see beginning of the session, it can't decrypt it - because key exchange hasn't been seen. Some sessions may not have been seen from the beginning, e.g. if AMD is restarted or if sessions last for days and have started before AMD has been enabled. When traffic feed quality is less than optimal, some packets may be missing and if first packets of the sessions were missing, then whole session won't be decrypted.

2% missing operations is not very high. Of course 0% would have been ideal, but it may be unachievable in practice.


sponnada2
Organizer

thanks Kris for the explanation.

so how can we avoid non sync sessions?Is high response time because of non sync sessions?

if it so, how can we turn it as sync sessions ?.


Monitored traffic quality maters most. If you use taps and lossless packet broker, then all packets should be forwarded to the AMD. SPAN will always drop something, very little, but it can't be expected that it always drops absolute zero.

Some non-syn sessions are inevitable if they last long and the've started before AMD started monitoring.

End of it all, total elimination may be not feasible so aim at good enough measurement quality and report separately on timing of operations that matter from performance perspective (per named URL, eliminating "encrypted operation" by filtering it out) and don't report on "response time" per server, as this mixes apples and oranges.