The site requires certain bits of content to be shown to users in an equal fashion. It doesn't matter if the user see's content "A" "B" or "C" only that those bits of content are seen in equal amounts by different users. So I have a variable that increments by one every page load and that determines which piece of content is shown (The client rejected a random number generator).
The problem is the speed at which I am able to update this variable. I have it saved as a property for a page and the time it takes to update that value is causing page load time issues. I believe it has to republiush the entire page every time someone visits it which is causing this.
How should I be saving this variable? Is there a better way than just a variable on a page (the type you can edit in the backend)?
But you have a couple of options - depending on your site structure/infrastructure/ etc
1: You could create a new table within Umbraco and store the volitile variable theres - you would need to store the contentID (or guid) and the variable, you should look at things like Fluidity and UI-O-Matic for getting this up and running quickly. you would still have an issue hitting the DB on every page load
[you could store things in the cache too, but changing every-page load sort of means it will be going back to the DB every-time too i suppose (see below - for what i would do to get around this)]
2 : you could just write to a file on disk (somewhere like app_data/ ?) I wouldn't recommend this if you are on any sort of cloud/virtual infrastructure as writing to disk can be super-slow - but in a hacky it just works sort of way - saving the value to a simple xml file in memory and saving it back to disk is a very simplistic version of what the Umbraco Cache is doing with content when you publish, but in principle writing to disk is a bit dirty
If it was me (and again i don't have all the background) - I would be inclined to increment the vales in memory (using the RuntimeCache) and have a peridoci scheduled job to save them into a custom table in the DB. - that way the impact on page load will be minimal, and the save will happen "out the back" somewhere limiting the impact on performance.
Risk of this is you could loose the values if the site goes down between page view and scheduled save - but thats not super probable but if the values are critical might not be the option you can go with.
Infact if this is just to distribute the load between three variants of the page, i would do it in all memory, not save it anywhere, and say they are loaded equally while the site is up?
It isn't three variants, what the number does is decide which what in practice is a Blog post to load. But posts are added and removed all the time. So right now there are about 60 different options but the number varies all the time.
But I think you have covered my options. From a quick look RuntimeCache is the best way forward. If the value is lost it is totally ok for the process to just start at 0 again as long as it is not a very frequent occurrence.
Best way to create store and update a variable that updates on every page load?
The site requires certain bits of content to be shown to users in an equal fashion. It doesn't matter if the user see's content "A" "B" or "C" only that those bits of content are seen in equal amounts by different users. So I have a variable that increments by one every page load and that determines which piece of content is shown (The client rejected a random number generator).
The problem is the speed at which I am able to update this variable. I have it saved as a property for a page and the time it takes to update that value is causing page load time issues. I believe it has to republiush the entire page every time someone visits it which is causing this.
How should I be saving this variable? Is there a better way than just a variable on a page (the type you can edit in the backend)?
Hi Richard,
yeah updating the content items lots of times isn't something Umbraco recommend - for the reasons your seeing really. (see https://our.umbraco.com/documentation/Reference/Common-Pitfalls/#using-umbraco-content-items-for-volatile-data)
But you have a couple of options - depending on your site structure/infrastructure/ etc
1: You could create a new table within Umbraco and store the volitile variable theres - you would need to store the contentID (or guid) and the variable, you should look at things like Fluidity and UI-O-Matic for getting this up and running quickly. you would still have an issue hitting the DB on every page load
[you could store things in the cache too, but changing every-page load sort of means it will be going back to the DB every-time too i suppose (see below - for what i would do to get around this)]
2 : you could just write to a file on disk (somewhere like app_data/ ?) I wouldn't recommend this if you are on any sort of cloud/virtual infrastructure as writing to disk can be super-slow - but in a hacky it just works sort of way - saving the value to a simple xml file in memory and saving it back to disk is a very simplistic version of what the Umbraco Cache is doing with content when you publish, but in principle writing to disk is a bit dirty
If it was me (and again i don't have all the background) - I would be inclined to increment the vales in memory (using the RuntimeCache) and have a peridoci scheduled job to save them into a custom table in the DB. - that way the impact on page load will be minimal, and the save will happen "out the back" somewhere limiting the impact on performance.
Risk of this is you could loose the values if the site goes down between page view and scheduled save - but thats not super probable but if the values are critical might not be the option you can go with.
Infact if this is just to distribute the load between three variants of the page, i would do it in all memory, not save it anywhere, and say they are loaded equally while the site is up?
Hi, Thanks for your response.
It isn't three variants, what the number does is decide which what in practice is a Blog post to load. But posts are added and removed all the time. So right now there are about 60 different options but the number varies all the time.
But I think you have covered my options. From a quick look RuntimeCache is the best way forward. If the value is lost it is totally ok for the process to just start at 0 again as long as it is not a very frequent occurrence.
Thank you.
is working on a reply...