Revamping the Cache Engine in FusionPBX

These last days of 2020 I have spent hours patching the "soon-to-be" FusionPBX 4.6. One of the things I don't like is the way the cache engine is designed. Since FusionPBX 4.4, there are two ways of doing cache:

• using a file system cache (default),
• using the classic Memcache

I will first talk about how they are now (Dec 30th, 2020) and what my published pull request will fix and enhance.

File System Cache in FusionPBX 

Available in FusionPBX 4.4 and turned on by default, the file system cache engine writes all its information in the directory specified by the default setting cache - location - text; by default, it points to /var/cache/fusionpbx. Personally, I  have never liked the way it is at this point:

• it adds unnecessary I/O, although this could be worked around using the tmpfs filesystem,
• it lacks an expiration mechanism therefore all objects created are valid until the given file is manually deleted. This could give some kind of persistence, but if fast I/O is your priority (tmpfs deployed), then persistent can't be archived.

Nowadays, hard disks are pretty fast, but they will never be as fast as RAM.

Enhancements and Fixes of the File Cache

My pull request adds the following:

• expiration mechanism

At this very moment, all the files are stored with the key as a file name. There is no way to specify somehow the expiration timestamp. My solution is simple, by adding a numeric extension with the unixtime (aka epoch time) of when that given object will expire. If an object with the key 'directory:100@mydomain' is created with an expiration date of January 27th, 2021 07:49:00, then the file This email address is being protected from spambots. You need JavaScript enabled to view it. will be created. Let's pretend the following actions:

• Set for a second time the same key: the PR will delete all the directory.100@mydomain.* files before creating again the new filename.
• Delete the key: the PR will delete all the directory.100@mydomain.* files.
• Read the key: the PR will get all the directory.100@mydomain.* files, then it will split the extensions and select the one with the highest value; and only if that selected value is less or equal to the current timestamp it will return the value, otherwise it will return a not found as usual.

If you are familiar with my pull requests, you will find a PR that fixes the Azure STT voicemail. The issue here is that because the current file cache engine lacks an expiration mechanism, the authorization token from Azure will expire and the LUA code won't be able to make a difference if it should reuse it or not. If you must use Azure STT, you can use this patch or switch to Memcached.

Memcached System Cache in FusionPBX

At this very moment, the PHP and LUA code in FusionPBX connects to the FreeSWITCH event socket and pushes Memcache commands through it. In my opinion, this has a lot of limitations, for starters: 

• You can't split the FusionPBX to another server. If you do anyway, you must have turned off a local FreeSWITCH daemon which is a waste of resources just to do cache operations.
• The Memcached server is always localhost. On big deployments (clusters), saving some database queries will make a difference in performance, then having a way to specify more than one server and a different port than 11211 is crucial. Please read my article about the Memcache Protocol Router to have an insight into Memcached clusters.

Enhancements and Fixes of the Memcached Cache

My pull request adds the following:

• ability to use the pecl-memcached package if present,
• ability to not depend on a local freeswitch to interact with Memcache,
• ability to specify a different Memcache server than 127.0.0.1:11211 and more than one Memcache server,
• if your PHP deployment has installed the PECL Memcached extension use it.

Please report to me any bug regarding this, I will gladly fix it as soon as possible.

Happy VoIP and good luck!