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

Citrix and Idle users generate insane network time

Jarmo_Jauhiaine
Newcomer

Hi,

I'm trying to figure out, why idle users in Citrix monitoring are generating insane network time. Channel is Thinwire. This is verified as Idling user from the NS insight. Insight shows 0 operations to current user.

Anyone else had this kind of monitoring issues with Citrix-Idlers?

Br,

Jarmo

6 REPLIES 6

ulf_thornander3
Inactive

What version?

I have seen similar things historically. When the client switches from Active to Passive (sleeping), the "heartbeat" Changes side and instead of the client requesting data from the server, the server starts asking the client (Are you alive?) which tilts the picture so the the response time becomes the time between the heartbeats.

Do I make sense? 🙂

adam_piotrowicz
Dynatrace Pro
Dynatrace Pro

Jarmo,

Aren't you on < 12.3.5?

Such problem has been fixed in 12.3 SP5.

Jarmo_Jauhiaine
Newcomer

Hola, we currently have version 12.3.3 and we're about to upgrade to 12.3 sp 8 ASAP. I'll report after the update if this kind of behavior will be gone.

Jarmo_Jauhiaine
Newcomer

Hi,

CAS And AMD is updated to 12.3.8. Overall is much better now, but we can still see some of idling sessions like this, but this time insight also shows some traffic to user.

ulf_thornander3
Inactive

If you promise not to laugh - The first time I saw the same thing was when I reported on a TN3270 session going to the mainframe.

As long as the user was working, they were sending requests to the MF and thereby established that they were the client and the MF was the "server", coming back with a ACK.

When the users stopped actively working, the MF would send a check to the client to see if they were still there. The client would respond "Yes". This response (not being decoded as a response) was interpreted as a request being sent to the MF, and then we would wait 30 minutes until the MF sent the next "Are you there", we would take that as the response to the previous "Yes", and that would yield a response time of 30 minutes 🙂

In the end I think we capped the max response time to 60 seconds for that decode as this was terminal traffic (which, ironically ICA also is).

Jarmo_Jauhiaine
Newcomer

Thank you Ulf and Adam for the fix and clarification for all this.