I am running SugarCRM on top of an ObjectiveFS shared filesystem. It has “okay” performance, but it’s not supposed to be treated like a scratch disk for “atomic renames” (file_put_contents() probably takes care of this already…?) - this is going to be the same with any network filesystem (NFS for example)
After taking a couple hours to finally narrow down where the issue was in a setup for a client, I traced it to the sugar_file_put_contents_atomic() function. Anyway, the main abuser of this is include/SugarObjects/VardefManager.php - the saveCache() method.
Is there a drop-in or simple way to replace this filesystem-based cache with something a little bit more scalable and cloud-friendly, like memcached or Redis? There’s other caching in SugarCRM I see, but there doesn’t seem to be anything for this. It’s 2016, we shouldn’t be stuck with only a file-based caching system. There shouldn’t need to a requirement for file I/O anyway for an expectedly volatile cache scenario… that’s exactly what read-through cache layers are for.
Meanwhile a couple hacks to proof of concept gained some performance back to nearly normal:
- sugar_file_put_contents_atomic() to call file_put_contents() directly
- changing $dir to /tmp - so the temp files are created on local temp scratch space before the rename
I am not a pro at SugarCRM, so I am not sure how easy it is to just override the Vardef cache methods - I might give it a shot but I don’t know the overall impact of this. There’s a lot of code to go through. It looks like this is SugarCRM 6.5.23 CE.
Note that I looked at SugarCRM 7.x (latest) and that saveCache() function still exists and looks identical. I’m curious, I see a call to store it in the cache, but when I was loading the site, it was consistently re-creating the vardefs files every single request, and this seems ripe for pure memory-caching (or even pre-generated DB blob…) - file system caching is not scalable either from I/O nor from a distributed/properly horizontally scaled approach.
// put the item in the sugar cache.
$key = “VardefManager.$module.$object”;
sugar_cache_put($key,$data);
Why is there no sugar_cache_get() or something on the read function? I am pretty sure that it’s not much more expensive and in a horizontal setup with a shared filesystem, it would be more scalable and faster to fetch one cache key and then eval() or just serialize() it beforehand so it can be unpacked with unserialize() and not have to eval()…