Slightly faster… but still faster!
Â
Bandwidth graph for sfo.thejof.com
Here’s an example of how poking into what your applications are really doing can really save you some compute resources. In early December, I was adding a new job to my crontab and wanted to go over all the things that were running from there.
One of these cron jobs was a script snippet to instantiate mbsync to synchronize my remote IMAP store at work to a local maildir for perusal with mutt. When I wanted to grab a capture of some example network traffic of some of its polling cycles, I was surprised to find that it was always SELECT-ing each folder and iterating through each UID to check if it had seen it before. This took a decent amount of bandwidth to poll every five minutes – around 200 kbps. And of course, with the remote mailstore being an Exchange shop, this stretched the polling cycles on big folders out longer than it should have, blurring the lines between the stop of one cycle and the start of another.
Taking a look at some of the alternatives for remote mailstore synchronization, I started taking a look at fetchmail and eventually settled on switching. By configuring it to use IMAP IDLE-ing, the same process happens faster at around only 5-20 kbps — an almost four-fold reduction in network utilization.
Efficiency victory dance!