PureEngage On-Premises

Dear all, 

For some statistics reason, we have to insert about 300 Virtual Queues DNS as an Origination DN in an Agent Group.

Before implementing that, I'd like to know if it can has an impact on the performance of my contact center.

Thanks by advance for your help

Best regards

#Unsure/Other

------------------------------
Karima Hatim
------------------------------

My first question would be Why?  That seems to be a very ineffective way of handling whatever you are doing.  I would rather put them in a call route that points to a flow.  That is much easier to manage and you can use a table to control routing or just ring them to the group.  

I am making an assumption here by DN, you mean DNIS or DID and by agent group, you mean a ring group.

------------------------------
Robert Wakefield-Carl
ttec Digital
Sr. Director - Innovation Architects
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com
------------------------------

I can't answer for sure but you'd definitely need to be keeping an eye on your Stat Server performance.  Might also be worth checking to see if there's a limit on how many Origination DNs you can add.  You'll also want to be considering very carefully how calls may traverse multiple VQs and how that may affect whatever you're capturing stats for.  I don't recall the impact of that.  Depending on what it is you're reporting on, you may be better off reporting from another angle.

------------------------------
Vaun McCarthy
------------------------------

Hi,

It is quite difficult to measure the impact this action could do in your environment. As far I recall, adding VQ DNs as Origination DN is to help track and link agent and vq statistics. The weight will be carried by the statservers. I suggest you add these VQs before midnight and after that check how statserver behave, also take a picture before the change. It should increase cpu and memory usage, so it is good idea how it performs now. Infomart should be also monitored.

Another suggestion is to delete from statserver any non used metric, filter, or time-range, keep the configuration to the minimum.

Regards,

SG

------------------------------
Saugort Dario Garcia
Arquitecto de soluciones
------------------------------

I would first attempt it in a lab and see if there are any system limitations as Vaun mentioned. 

In addition to looking at CPU utilization, before and after, you can look at your Production Stat Server's logs to see how many calculations its currently handling.  I forget the threshold Genesys states one Stat Server can handle, but it's over 250k.  We're over 300,000 stats on one Stat Server, so if yours isn't close to that, I doubt you'll have concerns about Stat Server.

Log example: 

18:18:01.979 Std 10060 Current load: clients: 5, stats: 300000, requests: 600000

------------------------------
Tony Morrow
Sr. Genesys Engineer
------------------------------