Talking Agent Count - CTI

[Omar Deen]

Before opening a TAC case, I figured I'll try to see if the community can shed some light on what I'm perceiving as an issue - correct me if I'm wrong though.

I havent noticed any noticable and agent impacting CTI issues, however, when I go into Performance Monitor and monitor Talking Agent Count for process ctisvr, the number is incredibly inflated and continues to increase. I've attached a picture of PerfMon at the bottom of the post. Additionally, I've noticed a lot of QueueMSG and unQueueMSG messages in the ctisvr dumplog, over and over. Is this a concern? Also, what exactly does it mean when this says Max Calls Ever? The number says 218 now, but it was 256 a few days ago.

Events from February 8, 2014:

00:00:00:027 cg1A-ctisvr Trace: CTIApplication::ProcessTimeNotificationEvent - Time=05:00:00 UTC NewHalfHour=TRUE

00:00:00:992 cg1A-ctisvr CTIServer ACTIVE, 8 CTI Client connection(s), 0 call(s) in progress, PG Status: NORMAL

00:00:00:992 cg1A-ctisvr Period connection(s): 0       Period call(s): 0 (0.00 calls/sec)

00:00:00:992 cg1A-ctisvr Period EnterpriseCTI traffic: 42844 messages (23.80 msgs/sec)

00:00:00:992 cg1A-ctisvr                               12589468 bytes / 1800 seconds (6994.15 bytes/sec)

00:00:00:992 cg1A-ctisvr                               1426 heartbeats (0.79 hb/sec)

00:00:00:992 cg1A-ctisvr                               1.12ms average queue time/msg

00:00:00:992 cg1A-ctisvr                               0.04ms average CPU time/msg (0.09% busy)

00:00:00:992 cg1A-ctisvr EnterpriseCTI Server version: Release 9.0.3.0 , Build 206

00:00:00:992 cg1A-ctisvr Build date:                   03/19/13 18:42:28

00:00:00:992 cg1A-ctisvr CTIServer UP time:            3 days 22 hours 11 minutes

00:00:00:992 cg1A-ctisvr EnterpriseCTI Meters from last: 24 hrs 0 min 0 sec

00:00:00:992 cg1A-ctisvr CTIServer-OPC traffic:        2323750 messages (26.90 msgs/sec)

00:00:00:992 cg1A-ctisvr                               968872080 bytes (11213.80 bytes/sec)

00:00:00:992 cg1A-ctisvr Active time:                  24 hrs 0 min 0 sec

00:00:00:992 cg1A-ctisvr Number of Connections Today:  0

00:00:00:992 cg1A-ctisvr Max Connections Today/Ever:   8 / 8

00:00:00:992 cg1A-ctisvr Number of Calls Today:        9208

00:00:00:992 cg1A-ctisvr Max Calls Today/Ever:         185 / 218

00:00:00:992 cg1A-ctisvr EnterpriseCTI traffic:        3077823 messages (35.62 msgs/sec)

00:00:00:992 cg1A-ctisvr                               760914617 bytes (8806.88 bytes/sec)

00:00:00:992 cg1A-ctisvr                               12578 bytes/sec (peak)

00:00:00:992 cg1A-ctisvr                               1 hb/sec (peak)

00:00:00:992 cg1A-ctisvr Invalid EntCTI Msgs Rec'd:    1

00:00:00:992 cg1A-ctisvr Max Global Transmit Queue:    305

00:00:00:992 cg1A-ctisvr Max Client Transmit Queue:    305

00:00:00:992 cg1A-ctisvr OPCResponse Min/Max/Ever:     2 / 87 / 712

00:00:00:992 cg1A-ctisvr OpenResponse Min/Max/Ever:    99000 / 0 / 5

00:00:00:992 cg1A-ctisvr HBResponse Min/Max/Ever:      0 / 2 / 2

00:00:00:992 cg1A-ctisvr CtrlResponse Min/Max/Ever:    3 / 13412 / 15030

00:00:00:992 cg1A-ctisvr OtherResponse Min/Max/Ever:   0 / 112338 / 199263

00:00:00:992 cg1A-ctisvr Max Xmit Delay Today/Ever:    1048 / 1722

00:00:00:992 cg1A-ctisvr Average Msg Queue/CPU Time:   0.90ms / 0.07ms (0.19% busy)

00:00:00:992 cg1A-ctisvr MessageQueue Min/Max/Ever:    0 / 35 / 146

00:00:00:992 cg1A-ctisvr MessageCPU Min/Max/Ever:      0 / 9 / 134

00:00:00:992 cg1A-ctisvr ValidateCall Errors Today:    3

00:00:00:992 cg1A-ctisvr 0 Active Call(s), 0 Total Call(s) in progress

00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued:  (1 msgs in the queue, max:15000)

00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued:  (2 msgs in the queue, max:15000)

00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued:  (3 msgs in the queue, max:15000)

00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued:  (4 msgs in the queue, max:15000)

00:00:04:625 cg1A-ctisvr Trace: TransportProtocol::QueueMSG - CTIOSServer (SessionID 3) , Message queued:  (5 msgs in the queue, max:15000)

00:00:05:625 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued:  (34 msgs in the queue, max:15000)

00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued:  (33 msgs in the queue, max:15000)

00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued:  (32 msgs in the queue, max:15000)

00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued:  (31 msgs in the queue, max:15000)

00:00:05:626 cg1A-ctisvr Trace: TransportProtocol::UnQueueMSG - CTIOSServer (SessionID 3) , Message unqueued:  (30 msgs in the queue, max:15000)

[david.macias]

Omar

I'll check my lab to see what comes up, but this just seems like a bad way to check for talking agents.  Is this more of a mental exercise or you don't trust what you're seeing in reporting?

david

[Omar Deen]

Hi David,

Customer has not complained about any reporting flaws (they use Exony VIM), however, when I was conducting a turnover session to their support team earlier this week, I showed them PerfMon as one of several ways to monitor as a health check. I had selected Talking Agent Count for the ctisvr process and was surprised to see such a high number. The turnover session was Tuesday and that number, at that time, was 3,500... it's now almost 25,000.

Thanks

[david.macias · Accepted solution]

Omar,

Finally got around to this, no I don't see such a high number for a ctisvr which has been in production for a while.  I am seeing a 3 digit number even though we only have 100 agents, but perhaps this is a cumulative number for the X past days.  So if your CC is bigger you might be ok.

Was looking at the wrong thing, I too have a very large number so I think you're right it's a total count probably since it was last cycled.

Let me know if you want me to check anything else.

david

[Omar Deen]

David,

Now that you mention is, this does seem to correlate with the ctisrvr process uptime. Looking at Portico right now and it tells me that the process has been up for 7 days, 20 hours, 52 minutes and 9 seconds which seems to be right on par with the moment I first looked at this counter in PerfMon. I had a turnover session to the customer last Tuesday morning and that number was in the low 200s and is now almost 30,000.

I ended up opening a  low-sev TAC case just get some answers, so I appreciate your contribution to this. I'm hoping to get the other aspect of this answered - what exactly is being calculated at the beginning of the dump with Max Calls Ever, Max Connections Ever, and all the other ones that have an Ever parameter. Does the number pertaining the Ever aspect count the total number since the process was last cycled?