DandyDialer version 1.7.0 brings performance improvements for handling large lists.


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.
Titon Barua


Titon Barua

Co-founder and Lead Developer

Titon is a software developer and architect with decades of experience in various web technologies, both in front-end and back-end. He prides himself in making robust and user-friendly software. An avid pythonista for a long time, these days, Titon mostly writes Clojure and Clojurescript.