XUI.ONE Caching System
I’ve always found performance of other platforms to be lacking, knowing full well that the bottleneck is MySQL, it just takes a lot of CPU to open a new connection to MySQL and run queries. This CPU expense is unfortunately exacerbated by the fact that the typical streaming platform has thousands of concurrent connections therefore requiring thousands of new connections to MySQL.
The obvious way around this was to implement a caching system for static data, and a synchronisation system to ensure modified information is then reflected in the cache. This was implemented fairly early in the development of XUI, however has matured significantly since and is now exponentially faster than its initial iteration.
XUI Caching System is enabled by default in more recent versions, relying heavily on a multithreaded Cron that runs in the background. On system start-up, every line, stream, episode and various other pieces of information are extracted from MySQL and stored individually on a file system that utilises system memory for instant access without IO bottlenecks. Due to the memory bound nature, enabling cache on services with significant amounts of streams or lines results in high CPU usage which needs to be accounted for. However, the trade-off of the high memory usage is significantly improved performance across the board.
In terms of setup, very little is necessary. As Caching is enabled by default you can just leave it run as is, however if you see large CPU spikes during caching cron runs you can reduce the Thread Count to ensure less cores and threads are utilised during the generation process.
The above shows an example of the Caching system active on a test server. The system compares the amount of generated cache files against the total in the database to ensure the cache is complete and up to date. You’ll see that the Streams in cache is 4 less than in the database, this is due to purposefully broken stream entries in the database designed to ensure that the cache engine doesn’t cache anything that wouldn’t work.
The Minute and Hour variables are in a Cron format, as they are designed to directly amend the Crontab to change the frequency the caching script runs at. The above example runs every 5 minutes of every hour, if you would like a more advanced view of how Cron works you can read the Wikipedia Article relating to it.
The Thread Count variable decides how many threads are utilised when updating the cache, the higher the number, the faster the process, however CPU usage will go up accordingly.
Update Changes Only switch tells the cache system to use timestamps to detect when a Stream or Line has changed versus the currently cached content, selectively updating only the items that the system believes to have changed since the last cron run. Disabling this option will make the entire cache regenerate at each cron run for higher accuracy, you would probably need to adjust the Thread Count and cron timing if you were to go this route, however it is not recommended.
Should I use Caching?
Absolutely.
This is one of the defining factors that sets XUI apart from the competition, and if you compare performance between XUI and other platforms you will see a marked improvement due to Caching as well as other factors such as better, mindful programming with a focus on security as well as performance.
