Caching mechanism; File cache. (Fast, Low Effort, Highly Performant)
-
Aleksi Ursin shared this idea 9 months ago
- Core System
- 2 Comments
3
Votes
Login to Vote
Caching mechanism is required.
A lot of portions of WHMCS are rather slow (or very slow), and this could easily be alleviated by very simple caching.
WHMCS barely utilizes any ram at all, everything is processed on the fly, multiple times over.
No memcached required here, but just a basic file cache mechanism which does atomic operations for coherence, no locking required.
Users can specify cache directory, so servers with fast NVMe could use the filesystem, or those wanting to utilize ram could set it to /dev/shm
This is fairly trivial to do even if building from scratch, as long as you have someone in staff who understands low level kernel (ie. how to make atomic file operations, the same functions work on each OS). The resulting class is only like 100 to 150 lines long.
At least Zen Framework, probably Symfony cache mechanisms are _very close_, might need to simplify for performance and rewrite as single class.
Why not memcached?
Memcached adds a ton of latency and WHMCS is too simple to require it (single server tens of billions of records is no issue, datasets in the 100s of gigs -- when coded right).
File cache on RAM is about 1000 to 10 000 times faster than memcached. I would suspect filecache on NVMe is still 10-1000x faster than memcached -- and vastly simpler to manage, build, debug, maintain. (ie. once built none needed). Memcached is only required on actually large datasets (terabytes) with high performance requirements.
Save those precious seconds of human time, 1000 actions a day is already dozens of minutes per person per day.
A lot of portions of WHMCS are rather slow (or very slow), and this could easily be alleviated by very simple caching.
WHMCS barely utilizes any ram at all, everything is processed on the fly, multiple times over.
No memcached required here, but just a basic file cache mechanism which does atomic operations for coherence, no locking required.
Users can specify cache directory, so servers with fast NVMe could use the filesystem, or those wanting to utilize ram could set it to /dev/shm
This is fairly trivial to do even if building from scratch, as long as you have someone in staff who understands low level kernel (ie. how to make atomic file operations, the same functions work on each OS). The resulting class is only like 100 to 150 lines long.
At least Zen Framework, probably Symfony cache mechanisms are _very close_, might need to simplify for performance and rewrite as single class.
Why not memcached?
Memcached adds a ton of latency and WHMCS is too simple to require it (single server tens of billions of records is no issue, datasets in the 100s of gigs -- when coded right).
File cache on RAM is about 1000 to 10 000 times faster than memcached. I would suspect filecache on NVMe is still 10-1000x faster than memcached -- and vastly simpler to manage, build, debug, maintain. (ie. once built none needed). Memcached is only required on actually large datasets (terabytes) with high performance requirements.
Save those precious seconds of human time, 1000 actions a day is already dozens of minutes per person per day.
2 Comments
Login to post a comment.
You already show some contents, so that would get preloaded into cache immediately.
But you could launch a request on the background to cache rest of the ticket too.
Better yet, when ticket list is loaded (full page loaded) start JS which preloads all the visible tickets into cache, or better even to the browser for the previews to load quicker; and those requests load into cache what is not present there yet. We are talking kilobytes of data here only.
Further opening a ticket is very slow.
Datasets are tiny, but somehow these are still slow.