Scaling of CM/Administration environment for Umbraco 8
Does anyone know whether it would be a problem if we scale the CM/Administration environment of Umbraco 8?
We are developing an Umbraco 8 site which will normally run as a single web app in production. So the single web app will act as both CM and CD. However, in rare situation, we might need to scale the web app to accommodate increased traffic.
I understand from here that we shouldn't scale CM/Administration environment, however this is written for Umbraco 7. Is it still applicable for Umbraco 8?
On the other hand, i have tried to run a test where i have 2 web apps connecting to the same DB, and I made content changes in both web apps. I haven't really yet noticed any issue as the updated content will be reflected in both web apps when i made changes in one of them.
But essentially yes the same advice remains - not to scale out the instance used for accessing the backoffice over multiple servers, it can cause 'issues' largely these are related to possible file locks, but also to do with how the backoffice may make several requests during a transaction, and these should be made to the same underlying instance... eg the world won't immediately end.. but weird things 'may happen'
One of the options is to have two web apps, one for back office, and one you can scale out to handle busy times - both sharing the same database instance, and using flexible load balancing to keep the published cache in sync.
Thanks for your quick answer.
Regarding the file lock issue, we have moved the media files to S3, and the content editors will not update macro, templates or partial views in the backoffice. In that case, I supposed we will not have file lock issues when scaling the CM environment?
Regarding the several requests during a transaction, are they request/transaction to the database?
But they will be publishing content? If they aren't during the period of scaling up, then there it is much less likely you'll run into problems with the lock on the nucache.db or examine indexes.
Which describes the kind of issues with locks, beyond media and template files, that may occur.
As I say the world won't end if you decide to scale up, it's just an unsupported configuration, as the operation of the backend isn't written or tested with that scenario in mind. It depends on how important it is your site is 'up' and maybe a quick rebuild of the nucache, or restart of the site, after scale out, if there is a boot issue, might be perfectly acceptable, but if you are autoscaling for high unpredictable demand it makes more sense to seperate the backoffice web app, and scaled a 'front end' web app as per the recommended approach.
My understanding The main issue I think you'll see, or be able to replicate and test yourself, is the performance of the backoffice on a scaled out web app. As you expand the content tree, those queries are cached for performance, but if in between clicks the api calls a different server in the scale out, you'll hit that delay again, (try clicking around the backoffice with the chrome dev tools open and look at the network requests, and imagine if they hit a different server) if the editor views the 'info' tab to display the url of the content... it may report the page is published but is not in the cache etc, yet...
... again it depends on the context of how the site is updated as to how likely you'll run into trouble.
Scaling of CM/Administration environment for Umbraco 8
Does anyone know whether it would be a problem if we scale the CM/Administration environment of Umbraco 8?
We are developing an Umbraco 8 site which will normally run as a single web app in production. So the single web app will act as both CM and CD. However, in rare situation, we might need to scale the web app to accommodate increased traffic.
I understand from here that we shouldn't scale CM/Administration environment, however this is written for Umbraco 7. Is it still applicable for Umbraco 8?
On the other hand, i have tried to run a test where i have 2 web apps connecting to the same DB, and I made content changes in both web apps. I haven't really yet noticed any issue as the updated content will be reflected in both web apps when i made changes in one of them.
Hi Beng
The documentation for load balancing in V8 is currently being updated, you can see some work in progress advice here:
https://github.com/umbraco/UmbracoDocs/pull/1964/files?short_path=30d3d5d#diff-30d3d5dde11eb1d153c5e0c28c64f48b
But essentially yes the same advice remains - not to scale out the instance used for accessing the backoffice over multiple servers, it can cause 'issues' largely these are related to possible file locks, but also to do with how the backoffice may make several requests during a transaction, and these should be made to the same underlying instance... eg the world won't immediately end.. but weird things 'may happen'
One of the options is to have two web apps, one for back office, and one you can scale out to handle busy times - both sharing the same database instance, and using flexible load balancing to keep the published cache in sync.
regards
Marc
Hi Marc,
Thanks for your quick answer. Regarding the file lock issue, we have moved the media files to S3, and the content editors will not update macro, templates or partial views in the backoffice. In that case, I supposed we will not have file lock issues when scaling the CM environment?
Regarding the several requests during a transaction, are they request/transaction to the database?
Hi Beng
But they will be publishing content? If they aren't during the period of scaling up, then there it is much less likely you'll run into problems with the lock on the nucache.db or examine indexes.
Have a look at this open issue: https://github.com/umbraco/Umbraco-CMS/issues/6546#issuecomment-541357000
Which describes the kind of issues with locks, beyond media and template files, that may occur.
As I say the world won't end if you decide to scale up, it's just an unsupported configuration, as the operation of the backend isn't written or tested with that scenario in mind. It depends on how important it is your site is 'up' and maybe a quick rebuild of the nucache, or restart of the site, after scale out, if there is a boot issue, might be perfectly acceptable, but if you are autoscaling for high unpredictable demand it makes more sense to seperate the backoffice web app, and scaled a 'front end' web app as per the recommended approach.
My understanding The main issue I think you'll see, or be able to replicate and test yourself, is the performance of the backoffice on a scaled out web app. As you expand the content tree, those queries are cached for performance, but if in between clicks the api calls a different server in the scale out, you'll hit that delay again, (try clicking around the backoffice with the chrome dev tools open and look at the network requests, and imagine if they hit a different server) if the editor views the 'info' tab to display the url of the content... it may report the page is published but is not in the cache etc, yet...
... again it depends on the context of how the site is updated as to how likely you'll run into trouble.
regards
Marc
That's helpful. Thanks Marc.
is working on a reply...