G
Guest
Hi there
My team is responsible for designing the architecture of the web hosting
environment in my orgnaisation. We plan to implement an IIS web farm, load
balanced by a couple of industry standard hardware load-balancers. One of the
things we are pondering at the moment is state persistence. A number of our
internal .net applications will require state to be persisted across the web
farm. So far our development manager seems keen on the idea of employing a
ASPNET State Server to handle persistance, which to my understanding will
require all the applications to be run out-of-process.
Two reasons why this might not be the best solution is a) applications set
to out-of-process will run slower than in-process applications, to what
degree I don't know, but there will be a difference. And b) with the state
server you add a single point of failure because to my understanding you
cannot web farm these servers. Perhaps there are ways to get around this
(windows clustering, etc)- interested to hear thoughts on this.
My question is - what would be the potential issues of using cookie
persistance as a solution for handling state across the board? That way
applications remain in-process and faster (unless generating cookies has a
performance impact too?) and we don't have to worry about putting a state
server in place and any resilience issues they bring up.
The only possible issue I am aware of is that users will have to enable
cookies - this wont be a problem internally, but we'll have to think about
whether we can make this a requirement for our external apps. The other issue
is to do with security but the secondary firewall capabilities of our load
balancers should be able to take care of that.
Any other issues to think about? My knowledge of this area is fairly limited
so interested to hear everyone's thoughts, tips, pointers to good literature,
etc.
Thanks,
NB
My team is responsible for designing the architecture of the web hosting
environment in my orgnaisation. We plan to implement an IIS web farm, load
balanced by a couple of industry standard hardware load-balancers. One of the
things we are pondering at the moment is state persistence. A number of our
internal .net applications will require state to be persisted across the web
farm. So far our development manager seems keen on the idea of employing a
ASPNET State Server to handle persistance, which to my understanding will
require all the applications to be run out-of-process.
Two reasons why this might not be the best solution is a) applications set
to out-of-process will run slower than in-process applications, to what
degree I don't know, but there will be a difference. And b) with the state
server you add a single point of failure because to my understanding you
cannot web farm these servers. Perhaps there are ways to get around this
(windows clustering, etc)- interested to hear thoughts on this.
My question is - what would be the potential issues of using cookie
persistance as a solution for handling state across the board? That way
applications remain in-process and faster (unless generating cookies has a
performance impact too?) and we don't have to worry about putting a state
server in place and any resilience issues they bring up.
The only possible issue I am aware of is that users will have to enable
cookies - this wont be a problem internally, but we'll have to think about
whether we can make this a requirement for our external apps. The other issue
is to do with security but the secondary firewall capabilities of our load
balancers should be able to take care of that.
Any other issues to think about? My knowledge of this area is fairly limited
so interested to hear everyone's thoughts, tips, pointers to good literature,
etc.
Thanks,
NB