CMS Capacities - Report Elements

[Stinney]

I really need a better understanding of report elements in reference to system capacities for running real time reports.

I understand that a report element can be a skill, vector or VDN.

So my first question is, if I run a real-time agent group report how is that counted towards elements in a real time report?

I'm also assuming that if I have a custom report that allows multiple skill reporting that each skill is counted as an element.

So in a Sun Blade 150, I can have 8 concurrent users running 5 windows with 4 elements with a refresh rate of 3 seconds (can only set it to 5).

If I have 1 user running 1 report, reporting on 25 skills at a 3 sec. refresh rate, I'm figuring that I'm over capacity by 5 report elements.

We have a system here that uses a login and monitors ALL skills in realtime and want to understand how it may be effecting this.

- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[AWYNOne]

Stinney, I just looked at one of my CMS boxes to list current users ("who" in unix). I have 69 people logged in. All have the capacity to run reports on any, and as many, skills or other report elements they need.

The capability to run reports is based on the CMS ID and what access you provision in "Feature Access".

Granted, if I have 69 people running real time reports with a 5-second refresh rate, my system will be taxed and may throw errors about real-time delays. But I have not run into any limitations on how many reports can be run at one time.

Hope that helps.

"If you always do what you always did, you'll always get what you always got!" Anonymous

 

[Stinney]

We are seeing performance issues due to the number of users logged in and the number of reports they are running at 5 second refresh rates.

What I'm trying to do is give feedback to the company and try to make recommendations as to what users should be allowed to do. Does everyone need to be logged in, does everyone really need 5 second refresh rates, how many windows can you really look at with 5 second refresh rates, should we scale back the number of windows and refresh rates, what do we recommend?

Unfortunately, our company uses a lot of Agent Reports and looking at Avaya's documentation, they recommend only having 30 agents in a real-time agent report and if possible, have them be concurrent agent ids (yeah, right) and if possible, limit how many agent reports are run and use skill reports instead.

This leads me to believe that the Agent Group reports consider each agent as a report element, which would also kill our performance. So I'm just trying to confirm it.

- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[multibus2]

Stinney, You are spot on, Agent Group reports can be system killers, as the agent group reports have to query the agent group table before it can query the agent tables and this will need to be done for each agent in the agent group. So these reports will require a lot more system resources than a agent report alone and thus agent group reports should only be used when there is no other way to report the data.

"Been there, done that and got the teeshirt

 

[Stinney]

So is it correct to say that each agent considered a report element?

Also, I'm getting 2 different interpretations of the "Percent refresh rate at 3 seconds" definition.

I'm saying that for our system, the capacity is 10% of the total concurrent supervisors (which is 80 for us), reports for supervisor session is 5 and the report elements are 4. So if refresh rates were set to 3 seconds (we seem to be only able to set them to 5) then we could only have 8 supervisors, running a total of 5 reports with 4 report elements (20 in total) before seeing system impact. This would mean that no one else could log in and run reports without impacting the system.

However, someone else is saying that this definition means that we can have 72 users logged in with an average refresh rate of 30 seconds and 8 additional users with refresh rates of 3 before we hit our system capacity.

One last item, I've also been told by an AVAYA CMS technician that the primary function of CMS is historical data collection. And that CMS will throttle back refresh rates to 60 seconds if it detects lag. I know how to run the lag time report in CMS. But I need to find documentation from AVAYA that states the primary function of CMS is historical data collection and that it will change the refresh rates of reports.

Sorry for the long post.

- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[multibus2]

This document may help you

http://support.avaya.com/elmodocs2/cms/CMS_capacities.pdf

"Been there, done that and got the teeshirt

 

[Stinney]

I have that document, it doesn't clearly answer the 3 second refresh rate question. I found a document that says CMS Supervisor (not the server) will actually increase the refresh rate to 1 min. if it detects lag in the reports.

- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[multibus2]

To be honest I doubt you will get a clear answer to the question as there are too may variables which can impact the real-time refresh rate

"Been there, done that and got the teeshirt

 

[europe]

In reality there is no clear answer.

One thing might help you out, check the maintenance log for error code 1501.

That one says:
SCREEN MANAGER error: system may be overloaded by real time reports behind by: XX seconds

I actually saw this at one customer site a few times



Please let me know if the information that was provided is helpfull.
Edwin Plat
A.K.A. Europe

 

[Stinney]

The error log is one of the items we've been using to show that there is significant lag in real-time reports.

I run it once a week and import it into a spreadsheet to create performance graphs.

We've submitted a ticket with Avaya to discuss in detail about some of this. They confirmed that an Agent is considered a report element. So right away that's one of our major issues as all of the supervisors use these to run real-time reports.

Still trying to get a definate answer on the 3 second refrsh rate, should have it Monday.

Avaya also said that CMS Supervisor will change the refresh rate if it detects lag, but supposedly will also put it back to the requested rate when the lag subsides.

- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[Stinney]

Avaya responded:

Each agent in an agent group report is a report element. So here we have groups of up to 50 agents, so one agent group report on one of these groups would be 50 report elements.

3 second refresh rates capacity. In our system we can have 80 users, 5 reports, 4 elements at 30 seconds. That's a total of 1600 report elements. So however we want to split it up we can have 160 report elements (10%) running at 3 second refresh rates. So for 80 users, they could all have 2 report elements running at this refresh rate.

CMS will throttle back real time refresh rates if it detects lag, but will also put the requested refresh rate back as the system recovers.

Hopefully I have one last question. Our system capacities is supposed to be 80 user logins, but we had 82 logged in yesterday. Our BP had told us this was a licensing restriction and that if 80 people logged in, that no more would be allowed to. But this seems to be erroneous.



- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[SF0751]

This might help on the CMS license info:

To view your current CMS license information:

Using ASA, sign into CMS with the CMS logon. Enter the command su root and enter the password for the CMS root logon ID. At the # prompt, enter the command cmssvc

This will return a menu of choices. Choose #1, "auth_display."

This will return a list of system authorized features. There will be an entry at the bottom that says: "Simultaneous CentreVu Supervisor Logins" and lists the corresponding number of licenses.


Susan
"Opportunity is missed by most people because it is dressed in overalls, and looks like work." - Thomas A. Edison

 

[Stinney]

We have 80 licenses, not questioning that. But we show 82 users were logged in.

So now I'm thinking that 80 only applies to the CMS Supervisor application and not if I were to access CMS through terminal emulator, which a couple logins do. But I don't think that changes the "capacities" from a number of report elements that can be run.

- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[Stinney]

UPDATE:

We setup a "site skill" for each office location. All agents in each site have been assigned this skill, but we don't route calls to it.

The supervisors are now running a skill status report on this skill to view what their agents are doing instead of real-time agent group reports AND they are using 20 second refresh rates.

I have had ZERO lag time error reports in CMS for a week now. AND the CPU utilization has significantly decreased as well.



- Stinney

Favorite all too common vendor responses: "We've never seen this issue before." AND "No one's ever wanted to use it like that before.

 

[SF0751]

Excellent news; thanks for the update.

Susan
"When the gods wish to punish us, they answer our prayers." - Oscar Wilde, An Ideal husband, 1893