DandyDialer version 1.7.0 brings performance improvements for handling large lists.
Background
Previously, we were using the most straight forward, but unoptimized way to queue the contacts in a campaign. This process was not performant enough to handle large lists. With some campaigns assigned more than 100K contacts, Dandy was gobbling memory like a ravenous little poodle; making the overall system slow to a crawl sometimes. We sustained for a while by applying a band-aid solution - doubling of the system memory.
A better solution
As a permanent solution, we rewrote a significant part of the campaign processing code. Contacts are now searched and queued in a batch of 5000, effectively making the effect of contact list size negligible on system responsiveness.
But there is a catch! Contact randomization, if enabled, is now batch-local. Formerly, contacts were randomized from all available ones. With batch-local randomization, agent utilization may take occasional dive, specially if list contains large pockets of bad leads. This is a necessary trade-off we had to make.
Additional changes
- Most of the search API now uses lazy database queries. This improves performance for first load of resource (campaign, gateway etc.) search result pages.
- Fixed a mercurial bug where campaigns were being suspended after connection to internal SIP server being disrupted somehow.
- Improved performance of contact search API. Contacts panel can now properly display contacts for very large lists. As a trade-off, we had to remove the sorting functionality from there.
