QueueMetrics > Running QueueMetrics

Large environment(s)

(1/2) > >>

mnail:
Hey, could anyone let me know of Agent limitation?

We have 700+ on a cluster - Reading docs state 2-200 Agents, is this s limitation of the software (i.e. heapsizes) or limited by hardware?

If this is a software limitation - can the systems be chained together as a cluster - showing Q's from another Queuemetrics system?

We have 400 Agents within 1 Q - 180 in 2nd Q etc..

Asterisk is handling this setup but custom loaded and highly tunned for our use.


Thanks

QueueMetrics:
The largest QM deployment I am aware of is about 500 agents. There is no hard limit in QM itself, and you can purchase multiple parallel licences at a discount price in order to have multiple reporting servers running on the same data set. Of course, running large reports on very large systems with a lot of parallel users requres a proportionate amount of RAM and MySQL I/O :)

mnail:
Good deal if it is a hardware thing - the I/O bottlenecks have been cleared up for us (cost but worth it) Ram Disk - all recording(s) happen within ram  - this started just as a means to not have early drive failure but proved worth its weight in gold.

I'll know as the next couple of weeks roll forward - Management always looks at the bottom line etc.. so we have to prove everything (Why/Why not).

It comes as an after thought to some (logging and monitoring that is) but thats what they pay us for - to think and then prove Why.

The ability to see reasoning (call disconnect, time etc to me is critical) staffing (we currently over staff) obviously not cost effective for any company, not to mention who was where when (aka - such n such was being paid but answer one call in the morning) that might work for small places with less hustle but we see it all the time "Gone fishing" just trying to keep it balanced.

We have some monitoring tools that happens now but they are trivial in comparison.

The CRD built into Asterisk is not correct - just meaning one cannot state Agent answered @ what time, wait time since the CDR handles (Start, answer, End, duration, billing times - but again The Q (switch) answered, not the agent.

Hard to get some to understand, surprisingly. Your app looks good to me and if we do not obtain it it will not be from lack of trying - just bad management call.

Still any work arounds I happen to find I'll post so others can have a shot at it should it help.

QueueMetrics:
Sounds thrilling :) We're here to help you if you encounter any problems.

mnail:
Just wanted to note for those who are checking out Qmetrics (first and foremost, I have no commercial interest in this product and receive no money if you purchase it – just wanted to be clear)

Anyways, as all management calls happen on a daily basis – I’m pleased with the ability of Qmeterics but have been pulled to roll a couple of sites before re-visiting this.

I noticed something initially I thought the java app was leaking ram – this was not the case though it was a leak in another application on our end. So even though I was granted the “go for it time” it has been taken back (always see a manager 100 miles away) see I even got to fix my own stuff!

They’re good people but you know how it is. (can ya do it in your spare time – sure if I had any :-)

Anyways just wanted to firm up where we are with this on a large environment and timetables have to shift since I primarily do the programming and backbone for our company. I can’t complain as I’m paid well but was digging the results I was obtaining from the Qmetrics product line.

I see as well 1.3.4 with user adjustable hours is coming so this just sparks more interest on my end. Thanks for keeping up the project and we’ll get back to ya and reclaim the time allotted.

Navigation

[0] Message Index

[#] Next page