Feedback

  • Contents
 

Limiting the Impact on Interaction Processor

When customizing or authoring handlers, be aware that each custom event or initiator causes overhead for Interaction Processor's thread count. While new Call or Interaction Disconnect, TCP/IP, SOAP, or CustomNotification handlers might work fine in testing or under a medium load, the thread count under a high load could be substantially higher than what CIC has been tested with in QA labs.

Here are some suggestions for limiting the impact on Interaction Processor:

  • Use existing customization points for Interaction or Call disconnect when possible.

  • When designing handlers, consider the maximum number of threads in the thread pool, which is set in Interaction Administrator. For more information, see the topic "IP Configuration" in the Interaction Administrator online help. The limit is set in Interaction Administrator after the handler publishes. If the number of events received exceeds the set limit, the messages are queued and run in order as the custom handlers terminate. Design for the possibility of queuing and  failures due to timeouts to minimize the impact of activity surges on call processing availability.

  • Do not excessively retry events that initiate handlers. If an event timed out, it could be because it was queued. A retry would result in two of the same event in the queue and would slow down the processing.

  • Limit the runtime of custom handlers. Require that handlers run quickly or fail due to timeout.

  • If you can perform an action from a CIC client or from Scripter, do so. When you send actions to Interaction Processor, you might gain access to convenient tools or database integrations, but it puts a scaling bottleneck into the design that is easily avoided if each individual client performs their own action.

  • Avoid excessive round trips of data with TCP/IP tools. These tools are good ways to get custom data to clients, but if that involves data that must be updated on the server with TCP/IP data back to the CIC server, be careful not to do that too frequently. An alternative is to use web services to update the data on a third server. You can have the CIC server send the initial data there along with its updates, and then have the clients send their data there along with updates to avoid the load on the CIC server.

ACD Queue Tips

Database Practices

Documentation Practices

Efficiency Practices

General Handler Authoring Practices

Handler Best Practices

Overall Project Tips

Overview of Building Handlers and Subroutines

Prompts

Troubleshooting Tips