I finally got around to trying this out in anger today and it works very well!
A couple of suggestions if OK:
1. in rbcUmbracoOnAzure.UmbracoApplication could you do a config check against your appsetting to see whether the server is the backoffice or not before registering the event handler. This avoids having a different global.asax for each deployment - I can send a pull request if you like, we've done this and it works well.
2. In your step by step you mention CDN based media, but other considerations would be Session state in App fabric (or SQL), if your site requires this and using the blob storage provider for Examine. Also, including the hostname of the server in the log4net filenames to prevent the aync logger trying to flush to the same file.
3. Since the package, Azure now has web hosting plans which would allow you to create a front end and back office site that scale independently without having to put the backoffice in Shared mode.
On points 2 and 3 I'd be more than happy to update the project page if you'd like to make me a collaborator.
FYI - I am presenting at the Umbraco UK festival on Friday and plan to demonstrate the package.
Glad you were able to get it up and running and decipher my monster install instructions - are you planning on using it in a prod environment? (I never got that far).
I made you a contributor to the github project - go ahead and make any changes.
1) I kind of get what you mean but am a bit lost - I'm assuming you mean to ignore the shutdown code that updates the db if the code is running on teh back office box - go ahead and make the change regardless and we can go from there.
2a) I've updated the readme with Session state info in the "What this package does not solve" section
2b) It's my understanding that you dont need to use Blob Storage for Examine since there is only one back-office? The front end boxes share their own Examine indexes on disk which I thought was fine? I vaguely remember talking to Shannon about this a while back.
2c) Yes, this is mentioned under "Other Notes" already - the other option is to log to SQL server and include the server name in your custom sql table - makes it a little easier to see what is happening across multiple boxes with a sql query rather than having to look at multiple text files. The MachineNameLogConverter.cs file is already part of the project to help with this.
3) Yep - makes things a bit easier - when I looked at this you had to do it all through Azure Powershell which was a bit painful.
I cant remember if I mentioned it somewhere else but in my testing 6+ months ago I found that a very basic site took >30 seconds to respond whenever you scaled manually in Azure - have you experienced the same thing? It was as if the scale functionality was doing a bunch of stuff in the background to "respool" the app - this issue is essentially what put me off using this approach moving forward.
Shannon has also made a ton of changes around bulk cache refreshes since I published this package - probably worth revisiting some of his public stuff to see if we could plug that in to make it perform even betterer.
Also interested to see your web.config transforms - I dont use those much on my projects but can see how they'd be useful here.
I made a couple of changes which you'll see committed - including install via nuget.
On 2b. Each instance will get a publish request and try and write to the examine index which could be probelmatic - as they are the same indexes for the front end servers and lucene writes aren't thread safe unless handled properly.
3. Happily Web hosting plans are now available through the portal.
I'm not seeing 30 second lags in scaling, but I'm only really toying with this at the moment.
I'm aware of the HQ work but haven't seen anything public to suggest there is official support yet.
I'll post some details on the transforms when I get a mo. This is something that I'll be dipping in and out of in the coming weeks.
For 2b - agreed that is an issue - I thought there was a web.config setting similar to umbracoContentXMLUseLocalTemp that made the Examine index write to the temp folder on each box therefore making them unique - I cant seem to find that setting now though.
rbcUmbracoOnAzure.UmbracoApplication
I finally got around to trying this out in anger today and it works very well!
A couple of suggestions if OK:
1. in rbcUmbracoOnAzure.UmbracoApplication could you do a config check against your appsetting to see whether the server is the backoffice or not before registering the event handler. This avoids having a different global.asax for each deployment - I can send a pull request if you like, we've done this and it works well.
2. In your step by step you mention CDN based media, but other considerations would be Session state in App fabric (or SQL), if your site requires this and using the blob storage provider for Examine. Also, including the hostname of the server in the log4net filenames to prevent the aync logger trying to flush to the same file.
3. Since the package, Azure now has web hosting plans which would allow you to create a front end and back office site that scale independently without having to put the backoffice in Shared mode.
On points 2 and 3 I'd be more than happy to update the project page if you'd like to make me a collaborator.
FYI - I am presenting at the Umbraco UK festival on Friday and plan to demonstrate the package.
Best,
Darren
Also - we added some web.config transforms so we could webdeploy to a front end and back end azure website using the same codebase.
As well as setting your "Is the back office" setting, we put in a rule to deny access to /umbraco on the front end site.
Hey Darren,
Glad you were able to get it up and running and decipher my monster install instructions - are you planning on using it in a prod environment? (I never got that far).
I made you a contributor to the github project - go ahead and make any changes.
1) I kind of get what you mean but am a bit lost - I'm assuming you mean to ignore the shutdown code that updates the db if the code is running on teh back office box - go ahead and make the change regardless and we can go from there.
2a) I've updated the readme with Session state info in the "What this package does not solve" section
2b) It's my understanding that you dont need to use Blob Storage for Examine since there is only one back-office? The front end boxes share their own Examine indexes on disk which I thought was fine? I vaguely remember talking to Shannon about this a while back.
2c) Yes, this is mentioned under "Other Notes" already - the other option is to log to SQL server and include the server name in your custom sql table - makes it a little easier to see what is happening across multiple boxes with a sql query rather than having to look at multiple text files. The MachineNameLogConverter.cs file is already part of the project to help with this.
3) Yep - makes things a bit easier - when I looked at this you had to do it all through Azure Powershell which was a bit painful.
I cant remember if I mentioned it somewhere else but in my testing 6+ months ago I found that a very basic site took >30 seconds to respond whenever you scaled manually in Azure - have you experienced the same thing? It was as if the scale functionality was doing a bunch of stuff in the background to "respool" the app - this issue is essentially what put me off using this approach moving forward.
Shannon has also made a ton of changes around bulk cache refreshes since I published this package - probably worth revisiting some of his public stuff to see if we could plug that in to make it perform even betterer.
Also interested to see your web.config transforms - I dont use those much on my projects but can see how they'd be useful here.
Regards,
Matt
Hi Matt,
I made a couple of changes which you'll see committed - including install via nuget.
On 2b. Each instance will get a publish request and try and write to the examine index which could be probelmatic - as they are the same indexes for the front end servers and lucene writes aren't thread safe unless handled properly.
3. Happily Web hosting plans are now available through the portal.
I'm not seeing 30 second lags in scaling, but I'm only really toying with this at the moment.
I'm aware of the HQ work but haven't seen anything public to suggest there is official support yet.
I'll post some details on the transforms when I get a mo. This is something that I'll be dipping in and out of in the coming weeks.
Best,
D.
Thanks for the update.
For 2b - agreed that is an issue - I thought there was a web.config setting similar to umbracoContentXMLUseLocalTemp that made the Examine index write to the temp folder on each box therefore making them unique - I cant seem to find that setting now though.
Regards,
Matt
Shannon mentioned the temp storage here: http://our.umbraco.org/forum/developers/api-questions/56303-Status-of-Examine-and-Azure-blob-storage-providers
I plan to give it a spin at some point today.
I'll let you know how it goes. I got stuck trying to write to blob.
is working on a reply...