Test Active Call Center's Reliability

We encourage users to carefully test Active Call Center and draw their own conclusions about the reliability of Active Call Center. Here are some ways that we test Active Call Center:

Memory and Resource Usage Profiling

We make extensive use of performance monitoring applications such as System Monitor (95/98/ME) and Task Manager (NT/2000/XP) to watch the amount of memory and operating system resources used while Active Call Center is running. Well-built, reliable applications tend to have stable memory and resource usage over long periods of time.

Active Call Center's memory usage and resource profile have been very stable in all of our tests. A slow increase in memory usage does take place as the size of the Call History grows and the database engine increases its cache of the Call History, but this memory is released when the Call Monitor is closed. Unless recorded audio is saved into the call history in mass quantities, the system should be able to handle many thousands of calls without noticeable performance penalties.

We do not put too much emphasis on the processor usage statistics because a single use of text-to-speech can briefly push processor usage to 100% on almost any processor. However, the speech tools shipped with Active Call Center are designed to have multiple instances running while efficiently sharing the processor as needed.

Crash Testing

When testing the Active Call Center service application, we created a tool to help simulate crashes and lockups. This tool provides a "fire drill" style simulation of the service and is an excellent way to see how the service handles fatal errors. This tool is included with the Active Call Center installation and can be invoked in VBScript Macros as shown below.

Cause a fatal crash:

Dim Crasher Set Crasher = CreateObject("ACCTools.Crasher") Crasher.Crash ' Causes an access violation.

Cause a lockup:

Dim Crasher Set Crasher = CreateObject("ACCTools.Crasher") Crasher.LockUp ' Script will hang here.

Crash testing will only be useful when running Active Call Center as a service. Otherwise, the program will crash and need to be manually restarted (not very exciting!).

Test Active Call Center Against Itself

Users that would like to get a firsthand idea of Active Call Center's raw call processing power might enjoy the following procedure we have used in our internal testing with Active Call Center 2.5.0:

Configure two Active Call Center systems. Open a performance monitoring application on both systems: either System Monitor in 95/98/ME or Task Manager in NT/2000/XP.
Open the answering machine example on the first system and set it to answer calls.
On the second system, use a spreadsheet to create a list of several thousand calls to the first system. Use commas and touch tones in the dial string to push through the Answering Machine menu. For example, assuming the first system is set up at 555-1212, the dial strings may look like this:

5551212,,,1,,,
5551212,,,1,,
5551212,,,,2,,,
etc.

Notice how the number of commas and duration are both varied in the different numbers. Create many different combinations to simulate different users' behavior.

On the second system, create a Call Tree that randomly leaves a message or hangs up. If both systems are using voice modems, the message may need to be a recorded wave file with high audio levels.
On the second system, choose Phone Calls ... Make Outbound Calls and then copy and paste the thousands of numbers from the spreadsheet. Click Make Calls and have the second system call the first system thousands of times.
Watch the memory and resource profiles in the performance monitoring tools on both systems. On our systems, our tests have run into the thousands of calls on both voice modems and telephony cards and have indicated exceptionally stable memory and resource usage profiles. However, results might vary across systems and we encourage users to verify these results themselves instead of taking our word for it.