We all have those projects we mean to get around to someday – those great ideas we want to implement, but there’s just no time, so they sit on the back burner. Here at 5000fish, we’re no exception, and so we’ve taken advantage of things being a little slower than normal due to the pandemic to focus on a few major development tasks.
One of those tasks is FastCache. This feature is something we’ve wanted to tackle for a long time, but it needed a focused effort – so we’re really excited to announce it’s ready to launch.
FastCache gives Yurbi users the ability to configure the scheduled execution of a dashboard, so when you go to view that dashboard, you get a near-instant display of cached data rather than a live query against a database.
Who Did We Create Fast Cache For?
Users accessing less-frequently refreshed data. If you’re doing reporting from a database that’s constantly refreshed, then it’s important to get a live query every time to ensure your reports are up to date. But if you’re pulling from a database that’s only refreshed on an interim, scheduled basis – say, once a day or twice a week – then there’s no reason to do a live query to pull the data again.
Customer-facing users. A common use case of Yurbi is embedded dashboards in our partner’s customer-facing apps. FastCache can be enabled on those embedded dashboards, where speed is important. No one wants to hamper the user experience by having to wait for a lot of reports to load, and with FastCache, you and your customer can get right to the report.
Users doing complex data blending from multiple sources. Pulling data from multiple dashboards, or unioning data from Excel or other sources into complex calculations can be a time-consuming process that creates a long wait time while your dashboard loads. With FastCache, you can set a refresh period so users can see data almost instantly.
Multiple simultaneous users. If you have a lot of users logging in at the same time, your database may be hit with high loads from multiple queries. With FastCache, instead of all those queries hitting the database live, a cached version is displayed.
What Makes FastCache Awesome?
There’s no tradeoff for speed. User security and personalizations are not ignored when providing cached data. The data displayed takes all user personalizations into consideration, including data security policies, dashboard filters, prompt preferences saved in dashboard widgets, and more.
You can still access new data. If you refresh a report or drill-down or apply a new filter, your dashboard will run a live query and you’ll have the real-time data at your fingertips. In this way, FastCache offers the best of both worlds — a fast initial display of cached data, but the ability to access real-time data as soon as it’s needed.
How is FastCache Configured?
Fast Cache is enabled at the user level – a setting in user permissions allows you to explicitly enable who gets cached data. This way it can be enabled just for VIPs, offered as an enhanced service to customers at an additional cost, or simply enabled it for everyone. It’s your choice.
Fast Cache can be enabled on a per-dashboard basis. Simply edit the dashboard configuration you want to enable Fast Cache on and set a refresh period. Out of the box, the refresh period is limited to no less than 30 minutes, but if you want to refresh more often, the limitation can be reduced in the app.config settings file.
We don’t recommend a refresh period setting that’s too frequent since a lot of users with FastCache enabled could keep the dashboard running continuously to keep the cache current. A more common use case would be a few hours or even a day or more depending on how often your data refreshes.
Once FastCache is enabled on the dashboard, it will take about three minutes to create the personalized cache files and load them into memory. A hover icon will appear on the user’s dashboard as a visual indicator that the report is cached. If a new filter is applied, the dashboard will refresh with live data, and if a new default view is set, the cache will remember that and use it for the next execution, so the dashboard that’s called up is the one the user expects.
What Else Should I Know About FastCache?
In the initial release, the dashboard is executed behind the scenes, one user at a time to limit the impact on the source data. In future releases we’ll add a throttling feature to enable you to set the number of executions you want at a time.
Cached dashboards are stored as files on the hard drive. While each file doesn’t take up a lot of space on its own, if you have a considerable number of users — in the thousands, say — you will need to keep an eye on storage space. Cached files are also stored in memory, so the dashboard displays very quickly. This way, if you reboot or recycle your server you won’t lose the cache; it will simply reload from the file system. Turning off FastCache in the dashboard removes all files from the storage system and memory.
If you have a multi-server implementation, currently it will run FastCache on all the servers. In future releases, only one server will need to run the dashboard, and the cached files will be deployed between all your servers.
How Do I Get Started?
It’s simple and seamless – just download the latest update file and apply it to your Yurbi server. Even though this release is a considerable update to our APIs, back-end and front-end services, and database, the upgrade is just as quick as you’re used to from Yurbi.
Just run the update file, wait about 15 seconds, and you’ve got FastCache power at your fingertips (be sure to clear the browser cache to get all the updates from the upgrade).