You have a successful contact center in operation and things are going well. The site isn’t having any issues with call quality, database latency, or agent portal usage. It’s a wonderful thing. You have a new client coming on board and all of a sudden, you need four times the capacity and throughput that your site currently handles and handles well. While the new business is certainly welcomed, how can you expand, efficiently and effectively, to meet these new requirements for your contact center?
Each component of your Asterisk based contact center (Asterisk, database, web, and Q-Suite in this case) will keep log files by default. Depending on what your call volume may be or how many agents you have logged in taking calls, these logs can grow very large and very quickly. Logs that grow very large and very quickly can consume a great deal of CPU and write resources on your servers. However, all of these logging mechanisms can have their levels of logging toned down or even turned off. While I wouldn’t recommend actively turning off any type of logging, taking the steps to trim the amount of logging done can help your servers focus on their proper tasks.
Asterisk uses AGI (Asterisk Gateway Interface) applications that can add an enormous amount of functionality to Asterisk with a number of different programming languages. While quite flexible and powerful, AGIs are very expensive operations on their own, and can be even more expensive depending on the type of functionality contained within the relevant piece of code on the other end of the AGI call. Your Asterisk server can potentially end up throttling itself if these operations are abundantly occurring. Incorporating a FastAGI server into your contact center can make a significant performance improvement on your Asterisk server as the FastAGI server allows the running of all AGI applications on a remote machine. Taking those system intensive operations off of your server will allow it work harder, faster, and smarter.
You may decide that dealing with some system configurations outlined in the two examples above is not your cup of tea and that is fine. Going with the old ‘just throw more hardware at it’ may be the solution for you. Concerned that your database server might not have the capability to handle the new loads? Get faster disks and more RAM. Web servers might not be optimal for the new influx of agents? Jack up the processing power of the server and give it more RAM. If you can handle the cost of having more power than you need, it’s never a bad idea to have some overkill on your contact center hardware.
I’ve just explained a few ways that you can help scale your call center when capacity planning is your main goal. It’s a good stepping stone to ensure that your contact center continues to perform admirably when more business happens to come your way.