Site Updates Without Downtime?
-
Scuse me if this is dumb, but... I always try to avoid having anything other than the bare minimum in session - usually just a guid - and I retrieve what I need from the db. What sort of stuff are you storing in session that requires you to replace components? I'm no web guru, so I'm probably missing something.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
We store things that are commonly used (eg yor name, your site filters etc) in session to avoid having to look that up each pane view. If you're storing just a GUID then I assume this means you're doing a DB lookup each time you need something? Or are you caching and looking up the cache using the GUID?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
:thumbsup: That sounds pretty darn amazing, and I'm amazed that my company isn't doing that or similar. However, we are currently doing some major analysis that is sure to bring about some huge changes, so I'm going to do my best to ensure part of what changes is the deploy process.
Setting it up and testing took at least a week of full time work by me, so it did cost a bit of feature development time, but the piece of mind and flexibility it got us has more than paid off.
Curvature of the Mind now with 3D
-
Whenever I make an update to the website I work on, it goes down for a few minutes. I know this can be avoided, and I even wrote an article and a personal website that demonstrates how to "live swap" on Azure to completely avoid downtime. We're just not there yet at my job. I'm curious: how many of you have a real/working live swap system to avoid downtime for the website(s) you work on?
AspDotNetDev wrote:
I even wrote an article
AspDotNetDev wrote:
to completely avoid downtime.
Please send that link to Apple, they seem to take the whole Apple Store down after every single keynote announcement. ;P
Remind Me This - Manage, Collaborate and Execute your Project in the Cloud
-
We store things that are commonly used (eg yor name, your site filters etc) in session to avoid having to look that up each pane view. If you're storing just a GUID then I assume this means you're doing a DB lookup each time you need something? Or are you caching and looking up the cache using the GUID?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Yep - that's essentially what I do - although I admit I'm not dealing with sites with 10M members so not sure how well scaled it would be ! Doing a DB Lookup of just what's required for that page is pretty quick - and SQL Server is remarkably good at caching for itself. I do sometimes cache frequently used stuff (and to be honest sometimes store it in session) such as the user name, if it is something that is likely to be shown on each page. Does storing the filters in session help at all - surely you have to pass the filters to the Db in order to provide the data - so could just as well send the userId as a single parameter and have the Db do it's thing with a join to the UserPreferences table?
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Nish Sivakumar wrote:
Does your Azure live swap technique retain session info?
No. Ideally, any website I build on Azure will not make use of session at all (haven't made a large website, so not sure if session can always be avoided, but it should be possible). However, my work website does retain session across updates. It does this by storing session in SQL server rather than in-memory (you set this up in the web.config). This required us to ensure all of our session objects are serializable, which meant that we had to replace some third-party components that were not serializable (I also vaguely recall having to replace a collection of type HashSomethingOrOther).
Ah, thanks.
Regards, Nish
Blog: voidnish.wordpress.com The life of a Malayalee American - by Nish
An article I recently wrote for an event souvenir
-
Scuse me if this is dumb, but... I always try to avoid having anything other than the bare minimum in session - usually just a guid - and I retrieve what I need from the db. What sort of stuff are you storing in session that requires you to replace components? I'm no web guru, so I'm probably missing something.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
We use a CMS (Umbraco) and we had a component installed in it that was internally using session for some reason. We found a workaround so we no longer had to use that component.
-
Whenever I make an update to the website I work on, it goes down for a few minutes. I know this can be avoided, and I even wrote an article and a personal website that demonstrates how to "live swap" on Azure to completely avoid downtime. We're just not there yet at my job. I'm curious: how many of you have a real/working live swap system to avoid downtime for the website(s) you work on?
We use a script to zip all files from the staging machine and copy the zip to our four live-servers. Over there we have a little winforms-tool (written by ourselves) to unzip to a release-x.y.z-folder and replace the stagin web.config with the live web.config. This is usually done in the eveneing before going live. The next morning we use the same winforms tool to select the release folder, hit publish and it just changes all path-mappings in IIS to the new folder. If soomething goes wrong we select the old (working) release-folder, hit publish and IIS-mappings are set to this folder. Remapping is faster than you saying "publish!". Downside: We have to do it four times (on each server).
-
We use a script to zip all files from the staging machine and copy the zip to our four live-servers. Over there we have a little winforms-tool (written by ourselves) to unzip to a release-x.y.z-folder and replace the stagin web.config with the live web.config. This is usually done in the eveneing before going live. The next morning we use the same winforms tool to select the release folder, hit publish and it just changes all path-mappings in IIS to the new folder. If soomething goes wrong we select the old (working) release-folder, hit publish and IIS-mappings are set to this folder. Remapping is faster than you saying "publish!". Downside: We have to do it four times (on each server).
Sounds like a good approach. Do you have a way to "prime" the website before the switch occurs? For example, whenever I change a DLL or web.config, the website has to recompile, and any unique page/masterpage has to recompile. Do you have a way of "visiting" some pages before making the switch to ensure everything is running smoothly?
-
Sounds like a good approach. Do you have a way to "prime" the website before the switch occurs? For example, whenever I change a DLL or web.config, the website has to recompile, and any unique page/masterpage has to recompile. Do you have a way of "visiting" some pages before making the switch to ensure everything is running smoothly?
Our site is already precompiled ([^]), but we also make requests to some "wake-up-pages".
-
Whenever I make an update to the website I work on, it goes down for a few minutes. I know this can be avoided, and I even wrote an article and a personal website that demonstrates how to "live swap" on Azure to completely avoid downtime. We're just not there yet at my job. I'm curious: how many of you have a real/working live swap system to avoid downtime for the website(s) you work on?
For IIS static web sites, just have a full copy of the modified site sitting in a unique folder: site/ v1/ <- current site, web site home directory v2/ Just update the web site home folder and click OK. site/ v1/ v2/ <- current site, web site home directory Just ensure that any cacheable resources are touched to force an expiration if they change from v2 to v1. (Unless you defeat caches) This also makes it super easy to fail back from v2 to v1. Again you have to be careful of timestamps. I am not sure if this would work with DotNet deployments.