CCPulse sessions per statserver

[dom74]

I've been supporting a relatively small (approx 250 agents) 6.5 environment for a number of years. We're about to roll out v7.6 to 600 agents and I'm told by the business that they would like to have the facility to allow 150 concurrent ccpulse sessions.

Can anyone give me an idea of how this many pulse sessions on a single statserver will affect performance? Our current setup only ever has 30 or so pulse sessions at any time and a single reporting statserver.

[phil]

Hi Dom,

we were running 7.6 with about 600 Agents earlier, but we hadn't had that much CCPulse sessions. This big ammount would mean 1 supervisor on 4 Agents. Ok, whatever the business says.
However, it depends on several factors like installed Applicatons on that host and complexlity/size of the workspaces. Further, u can adjust the Update-Rate in CCPulse to minimize traffic.
Unfortunately i can't provide real exprience with that, but i'd say that the StatServer is able to handle this ammount on session properly.

[dom74]

Thanks for that Phil. I'm not convinced that they'll ever get anywhere close to the 150 concurrent connections.  As you've mentioned we can just tweak the update rate in the unlikely event that they ever get to a level that causes issues with statserver.

[rpenney]

Hi Dom,
  It depends 

The problem is not the number of connections but the total number of statistics being monitored by all the sessions and the update rate.
If all the CCPulse sessions are looking at all the agents, then you will definately have problems. Once the number of stats gets into the hundreds of thousands, expect issues.
Data sourcer is the biggest cuplrit as it tries to get the stats all at once every 15 mins. I have seen Stat Server become unresponsive as it tries to send stat updates.

As Stat Server is still single threaded, you might be better having multiple stat servers on one box rather than just one process. Assuming everyone is not setting up their own views, setup the workspaces to use different stat servers for different views i.e. one workspace for managers to one stat server, one workspace for supervisors connected to a different stat server.

As Phil said, tweaking the update rate is a good strategy, also look at using changes based stats so they are only updated when the value differs by a set amount.

Russell

[tony]

..A couple of other aspects...

If all of your CCP Users are using the same Views/Templates and thereby the same refresh rates, the load on the StatServer is greatly reduced.  This is because the Stats will be sent out simultaneously, to all of the Clients.  A good trick is to maintain the .stg files centrally (on a LAN), rather than locally (on a Users' PC) - in this way, you can be sure that all of the Views/Templates are requesting the same Stats... Take a look at the CCPulse+ Application in CME - in the Options you can specify the location of the .stg's - pick a suitable Network location available to all Users and upload them to there ([b]Read Only[/b], of course! )

- I'm not sure why Data Sourcer would be considered an issue - unless you are using the same StatServer for both Historical and Real-Time Reporting... This is not really something I would recommend unless you actually have Historical Reporting enabled within your CCPulse+ Build...

Tony

[rpenney]

Tony, mentioning Data Sourcer was my fault 

I was just using Data Sourcer as an example of how Stat Server works and the potential for problems to happen with large numbers of stats being requested at the same time. It is not a problem for Dom.

I wrote the stuff about Data Sourcer and edited it until it didn't make sense anymore, well it made sense to me, just not anyone else 

However...

"This is because the Stats will be sent out simultaneously, to all of the Clients" - Is that actually true? My understanding of Stat Server suggests that would not work as it is dependent on when the client (CCPulse) requested the stat be created. Stat Server would send the update to each client seperately.

Russell

[Steve]

Going back to the original question -

You need to think about how many pulse users will be required for 600 agents. 150 seems high...but if it is a requirement.

Then how many views will each user need? and how many stats on each view?  Genesys recommends that Pulse views are restricted to 2,500 statistical requests to avoid performance issues.

Once you have worked that out you can look at the server running statserver. Genesys provide a  formula for determining the memory requirements of a Stat Server application.
MemoryReqd = 50 + (Nstatistics x 0.001)
Nstatistics refers to the number of statistical requests being made by client applications.

We set a limit of 100,000 statistical requests on a Stat Server that is deployed specifically for real-time reporting. We also set the refresh rate to 10 seconds for "Current" statistics and 45 seconds for everything else (Totals, Averages etc)

[dom74]

Thanks all for our replies. We currently have our stg files stored in a central location (as Tony suggested) and only use about a dozen different workspaces. This has enabled us to set the update frequency to 2 seconds. 

It would seem that until we're given some more information relating to the new setup its difficult to give the business a definitive answer. All of the information that you've provided will prove very helpful however so thanks again.