Re: Site Maintenance - HttpModule
- From: "Gregory A. Beamer" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 10 Jul 2009 05:25:42 -0700
nospam@xxxxxxxxxxx wrote in news:70ad52dc-6de1-4cba-84fe-dae40860d304
@h8g2000yqm.googlegroups.com:
All
Architecture:
An aspnet website serves as the interface for several scalable
applications.
Problem:
The ability to put the website into maintenance mode is required. The
maintenance mode needs to be selective - conditional on origination IP
address to allow internal personnel to view the site during a
deployment operation, and either the whole site or certain sections
may need to be selectively put into maintenance. Also, we want to
minimise the risk of killing a user's session while they are in the
middle of a workflow operation.
I am running out of time this morning, so I will have to examine
thoughts later. Here are a couple of things that can help.
1. Depending on how you are caching user information, you can often
"maintain" provided it is just a short "update the code" without killing
the user if you set up session state in SQL Server. This slows down
session state a bit (not bad), but takes the session out of the server.
You can also use an external session server (separate from all boxes in
the web farm) to accomplish the same thing, but that requires a separate
box, which you may or may not have.
2. For updating a site, it is better to stage on the local server in
another folder. You then set up a separate "site" to run through and
sanity check the deploy. As long as both sites are set up equivalently
in IIS, you should have no issue, as you are on the same box. Once you
are comfortable with the changes, xcopy over to production, except
perhaps the web.config (if you have different versions).
NOTE that you can still munge up a user in a single web box scenario if
he hits the site right as you are copying bits over, so nothing is
foolproof. But, with most sites, a local copy of the bits takes a few
seconds, so the likelihood you hit someone in mid request is pretty
small.
A better option is to have a web farm for the site(s) you manage. You
still need an external session mechanism (SQL or session server), but
you can take one server down and upgrade (even check the validity of the
code locally) and then bring it back up and start on the other server
(s). The user will never know any box went down if they are working, as
there is always a box that is serving them
I looked briefly at your HTTP Module methodology. I will have to think
about it, but it seems it could work. The question is why would you
incur this much work if you can simply move state off the web boxes (can
be done in the web.config).
Oh, one gotcha on a web farm. Make sure you manually set the keys in the
web.config file, as two machines will generate separate session keys
(ouch). I tend to do this out of habit, as it sets me up for web farming
from the start.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com
******************************************
| Think outside the box! |
******************************************
.
- Follow-Ups:
- Re: Site Maintenance - HttpModule
- From: nospam
- Re: Site Maintenance - HttpModule
- References:
- Site Maintenance - HttpModule
- From: nospam
- Site Maintenance - HttpModule
- Prev by Date: Re: How to do this Twitter About page functionality in ASP.NET
- Next by Date: Multiple page load error
- Previous by thread: Site Maintenance - HttpModule
- Next by thread: Re: Site Maintenance - HttpModule
- Index(es):
Relevant Pages
|
