vicidial.org

What is the biggest vicidial existing installation in one location in terms of number of seats?

What is the recommended max number of position to handle in a an vicidial installation.

The page http://www.callcentersg.com/design.php doesn't mentions an upper limit to the number of seats, but what would be a safe limit?

Thx

really depends on the factors of campaign setup

There's no such thing as a 300 seats single outbound campaign schedule. They will have to break it up to teams and shift. So either way you can have maximum number of seats with as many as vicidial multi servers catering to different campaigns.

The limit will be your imagination on how to implement it.

I know of an installation with 260 seats in a single location(2 separate buildings though). Aside from that, there are several call centers running VICIDIAL with 100 seats in a single location. There are also a few call centers from 200-400 seats that have several locations, but they all use the same core VICIDIAL system.

The upper limit really depends on your network and what kind of database server you use, aside from those two limiting factors, you can add VICIDIAL servers as long as you want to add capacity.

If you know how to partition the load over multiple machines you can go for a one-million-agent call center then get yourself a good admin to script campain creation & lead loding for you.
In my opinion put one dialer & one db server for each group of 20 agents or less. it will make 10 machines per 100 agent ( a crowded sever room ?) but a redundant one too, & you will never hear the terms of cpu or load in 20 years

The best suggestion is to create separate vicidial servers for each campaigns

Not unless you want to contribute or ask matt to be your consultant to start coding the mysql database to be able to support clustering in mysql servers. Where you can setup a cluster of vicidial database servers so that you will have no problem supporting many seats on a single database.

mflorell wrote:I know of an installation with 260 seats in a single location(2 separate buildings though).

257, actually. :-)

With current hardware technology 1000 agents is about the upper limit you can get onto one dialing cluster. This would require buying the most powerful database server you can possibly get. A 4X quad core processors (16 cores total), as much RAM as the system will take, and a RAID 10 with a GOOD hardware raid controller comes to mind.

So... your homework for 3.0 is: Why?

And how do we fix it?

Profiling an app this distributed won't be easy; take notes, there's a conference paper in it.

Fixing the capacity limitations of a single VICIDIAL cluster is not technically very difficult, just extremely time consuming. It would involve moving several things(not leads or logs, but real-time channel data and temporary tables, etc...) out of the database and into more efficient real-time data interchange protocols. That alone should allow a much higher single cluster capacity.

So you'll do that the first time a client wants to pay for it. :-)

Pretty much, like a lot of good ideas, it just takes time and money to make them happen.

Would that change imply to move away from ACQS into something equivalent to EventMachine (http://rubyeventmachine.com/) ?

I would prefer not to add another programming language to the project if possible. Most likely the protocol will be very light-weight and there will be some kind of fast memory data storage engine to keep track of everything.

Of course this is pretty far in the future at this point.

Yes, of course messing with another language does not make sense. It was just a an example.
I was thinking about a light socket based server running in the corresponding asterisk server and posting all ACQS related operations to a sqlite3 database stored in memory.
That could boost the performance.
But then again it is only thinking outloud.
It is clear that there are many other more important things in the pipe.

When it gets to the point where we have a proper testing setup to accurately simulate 500 or more agents logged in on multiple servers then we will try to evaluate several different fast data storage engines, and possibly make the storage engine interface interchangable between a few different technologies.

A more immediate change that could be tested, without having to modify the code would be to define the vicidial_manager table as a memory table, see http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

Yep, but not until I force MySQL 5.0 or higher. Which will be after the next release.

That table uses auto increment which you cannot do in HEAP(MEMORY) tables in 4.X MySQL.

There are several tables that you can change to HEAP in MySQL 4.X, and these are already changed in SVN trunk for the next release.