If you’ve been concerned about slow Asterisk startup times or excessive memory utilization, we’ve got some good news for you.  We’ve eliminated the media index cache that gets built when Asterisk starts.

Currently, when Asterisk starts, one of the tasks is to do a scan of /var/lib/asterisk/sounds and build an index of every sound file, for every format, for every language.  Even if you only have the English language files installed, that’s close to 20,000 files.  Some Asterisk users symlink their voicemail directory into the sounds directory tree for convenience so the indexer adds those files as well.  In fact, one customer recently had an effective sound file count of over 800,000 files which the indexer happily tried to index.  Well, until it caused the Asterisk process to run out of memory anyway.  While investigating that particular issue we discovered two very important points.  First, there were only 2 users of that cache, the “core show sounds” CLI command, and the “/ari/sounds” ARI resource.  No call processing flows used the cache at all.  The second point we discovered was that the cache was no faster than going directly to the filesystem to build the index.

The cache was added back in Asterisk 12 and I’m sure the original reasoning for building the cache (hopefully) included more than just the 2 use cases mentioned but it’s been over 3 years and none ever panned out.   Given that the 2 use cases didn’t involve call processing and that they were seldom used, it was hard to justify keeping the cache.   When we looked at performance with and without the cache we were a little surprised that it made no difference but we really shouldn’t have been.  The cache didn’t have any actual audio in it, it was just a list of files and which languages and formats they were in but that’s exactly what the directory structure of /var/lib/sounds represents!   Given that the chances of the filesystem caching it’s own directory structure in memory approach 100%, we were just caching what the filesystem already had cached.  OK, time for the cache to go.

So, Asterisk 13.25 and 16.2 will roll out without caching of the media index.  What happened to the response time of the CLI commands and the ARI resource now that they scan the directory structure for every call?  It actually went down slightly because we did some refactoring in the media index.  When I say “slightly” I mean it.  With an index containing about 30,000 files, it previously took about 0.07 seconds to retrieve the index from the cache and it now takes 0.05 seconds to get it directly from the filesystem.  It actually takes about 4 seconds to build a JSON response with the resulting data so data retrieval wasn’t the long pole in the tent anyway.  Why does it take 4 seconds to build a JSON response?  That’s a story for another time. 🙂