472,103 Members | 1,066 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,103 software developers and data experts.

Using ASP.NET StateServer on another machine. So what?

I understand the benefit of pushing the StateServer process onto
another computer to "balance" the load and take some cpu and memory
usage off the web server, but how much could it possibly help?
Especially when you're talking about marshalling the data back and
forth across your network (although on the same segment)?
Here's my scenario: Each login stores exactly 3 session variables; one
integer and two strings. That's it. Never, ever, is anything else
ever stored in a session. We have a couple hundred users. So what?
I mean, how much could moving the StateServer process to another
computer REALLY help? I tried it but don't notice anything. This
week, I'll be monitoring memory and cpu usage but my initial trials
show nearly no difference at all... might as well use that other PC
for something more useful.
Thoughts?
Nov 18 '05 #1
8 2120
It is useful for a few reasons.

1. When you use InProc the session variables can be lost when the process
gets recycled.
This is the main reason for using StateServer. (Even if it is on the same
local box. You do not need 2nd box just for State Server.)

2. Web Farms can have multiuple boxes all pointed to the same State Server.
This lets you avoid "sticky sessions". Then you can truly load balance the
servers in the farm.

--
Joe Fallon

"GeekBoy" <ge*********@yahoo.com> wrote in message
news:b0**************************@posting.google.c om...
I understand the benefit of pushing the StateServer process onto
another computer to "balance" the load and take some cpu and memory
usage off the web server, but how much could it possibly help?
Especially when you're talking about marshalling the data back and
forth across your network (although on the same segment)?
Here's my scenario: Each login stores exactly 3 session variables; one
integer and two strings. That's it. Never, ever, is anything else
ever stored in a session. We have a couple hundred users. So what?
I mean, how much could moving the StateServer process to another
computer REALLY help? I tried it but don't notice anything. This
week, I'll be monitoring memory and cpu usage but my initial trials
show nearly no difference at all... might as well use that other PC
for something more useful.
Thoughts?

Nov 18 '05 #2
For those two reasons, I agree completely. However, for one webserver
how much of a difference could it possibly make? I think, if you're
careful with your session variables (I only have three simple types)
then it might even be worse performance including the latency across
your network... so, why bother storing it on another machine? Has
anyone noticed any performance increase by off-loading the state
server to another machine?
"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote in message news:<uC**************@TK2MSFTNGP12.phx.gbl>...
It is useful for a few reasons.

1. When you use InProc the session variables can be lost when the process
gets recycled.
This is the main reason for using StateServer. (Even if it is on the same
local box. You do not need 2nd box just for State Server.)

2. Web Farms can have multiuple boxes all pointed to the same State Server.
This lets you avoid "sticky sessions". Then you can truly load balance the
servers in the farm.

--
Joe Fallon

"GeekBoy" <ge*********@yahoo.com> wrote in message
news:b0**************************@posting.google.c om...
I understand the benefit of pushing the StateServer process onto
another computer to "balance" the load and take some cpu and memory
usage off the web server, but how much could it possibly help?
Especially when you're talking about marshalling the data back and
forth across your network (although on the same segment)?
Here's my scenario: Each login stores exactly 3 session variables; one
integer and two strings. That's it. Never, ever, is anything else
ever stored in a session. We have a couple hundred users. So what?
I mean, how much could moving the StateServer process to another
computer REALLY help? I tried it but don't notice anything. This
week, I'll be monitoring memory and cpu usage but my initial trials
show nearly no difference at all... might as well use that other PC
for something more useful.
Thoughts?

Nov 18 '05 #3
You're right, you'll loose performance. If durablity is not important
to you, I wouldn't bother with a stateServer.
--
Xavier Pacheco
Xapware Technologies Inc

manage your projects: www.xapware.com/ActiveFocus.htm
the blog: www.xavierpacheco.com/xlog
the book: http://www.amazon.com/exec/obidos/AS...vierpacheco-20
Nov 18 '05 #4
You will never get a perfromance increase when moving from InProc to State
Server.
You will always get a decrease.

What you get in trade is increase in stability.
--
Joe Fallon


"GeekBoy" <ge*********@yahoo.com> wrote in message
news:b0**************************@posting.google.c om...
For those two reasons, I agree completely. However, for one webserver
how much of a difference could it possibly make? I think, if you're
careful with your session variables (I only have three simple types)
then it might even be worse performance including the latency across
your network... so, why bother storing it on another machine? Has
anyone noticed any performance increase by off-loading the state
server to another machine?
"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote in message
news:<uC**************@TK2MSFTNGP12.phx.gbl>...
It is useful for a few reasons.

1. When you use InProc the session variables can be lost when the process
gets recycled.
This is the main reason for using StateServer. (Even if it is on the same
local box. You do not need 2nd box just for State Server.)

2. Web Farms can have multiuple boxes all pointed to the same State
Server.
This lets you avoid "sticky sessions". Then you can truly load balance
the
servers in the farm.

--
Joe Fallon

"GeekBoy" <ge*********@yahoo.com> wrote in message
news:b0**************************@posting.google.c om...
>I understand the benefit of pushing the StateServer process onto
> another computer to "balance" the load and take some cpu and memory
> usage off the web server, but how much could it possibly help?
> Especially when you're talking about marshalling the data back and
> forth across your network (although on the same segment)?
> Here's my scenario: Each login stores exactly 3 session variables; one
> integer and two strings. That's it. Never, ever, is anything else
> ever stored in a session. We have a couple hundred users. So what?
> I mean, how much could moving the StateServer process to another
> computer REALLY help? I tried it but don't notice anything. This
> week, I'll be monitoring memory and cpu usage but my initial trials
> show nearly no difference at all... might as well use that other PC
> for something more useful.
> Thoughts?

Nov 18 '05 #5
I recognize that -- my question was more: What kind of performance
change will you see when you move the State Server off of the web
server onto a different dedicated computer?
So far I notice not much change. There are currently almost 500
active sessions and the computer is basically asleep with 1-2% cpu
utilization and 168MB memory usage. Meanwhile, the web server has
about 478MB memory usage and the CPU usage varies as usual...(both
machines have a gig of memory and two CPUs). I completely turned off
the ASP.NET State Server service on the web server and it freed a bit
of memory but not much. Again, I don't see much change. I'm
wondering why this is good? Now I have TWO computers that could fail
and bring the website down. That's twice the opportunity for failure
than one machine. Is this standard practice? I guess I'll walk
around the company and ask some heavy-load users if they notice
anything different. Users are always eager to complain. By the way
-- what makes the "State Server Sessions Active" counter go down in
perfmon? The "abandoned" counter is at around 650. "Timed out" is at
0. "Active" sessions counter never seems to get smaller.
Thoughts on all this rambling?
"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote in message news:<uz**************@TK2MSFTNGP15.phx.gbl>...
You will never get a perfromance increase when moving from InProc to State
Server.
You will always get a decrease.

What you get in trade is increase in stability.
--
Joe Fallon


"GeekBoy" <ge*********@yahoo.com> wrote in message
news:b0**************************@posting.google.c om...
For those two reasons, I agree completely. However, for one webserver
how much of a difference could it possibly make? I think, if you're
careful with your session variables (I only have three simple types)
then it might even be worse performance including the latency across
your network... so, why bother storing it on another machine? Has
anyone noticed any performance increase by off-loading the state
server to another machine?
"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote in message
news:<uC**************@TK2MSFTNGP12.phx.gbl>...
It is useful for a few reasons.

1. When you use InProc the session variables can be lost when the process
gets recycled.
This is the main reason for using StateServer. (Even if it is on the same
local box. You do not need 2nd box just for State Server.)

2. Web Farms can have multiuple boxes all pointed to the same State
Server.
This lets you avoid "sticky sessions". Then you can truly load balance
the
servers in the farm.

--
Joe Fallon

"GeekBoy" <ge*********@yahoo.com> wrote in message
news:b0**************************@posting.google.c om...
>I understand the benefit of pushing the StateServer process onto
> another computer to "balance" the load and take some cpu and memory
> usage off the web server, but how much could it possibly help?
> Especially when you're talking about marshalling the data back and
> forth across your network (although on the same segment)?
> Here's my scenario: Each login stores exactly 3 session variables; one
> integer and two strings. That's it. Never, ever, is anything else
> ever stored in a session. We have a couple hundred users. So what?
> I mean, how much could moving the StateServer process to another
> computer REALLY help? I tried it but don't notice anything. This
> week, I'll be monitoring memory and cpu usage but my initial trials
> show nearly no difference at all... might as well use that other PC
> for something more useful.
> Thoughts?

Nov 18 '05 #6
Hi GeekBoy:

The answer is always - it depends. The answer depends on how much data
you keep in session, the type of data you keep in session, and how
performant those types are at serializing themselves into session
state, etc. etc.

You have the right approach - you have to test and take benchmarks and
measure. What might not be a noticable impact for you could be a
signifigant performance drop for someone else's application.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On 18 Oct 2004 07:34:16 -0700, ge*********@yahoo.com (GeekBoy) wrote:
I recognize that -- my question was more: What kind of performance
change will you see when you move the State Server off of the web
server onto a different dedicated computer?


Nov 18 '05 #7
Thanks for your reply, Scott. Nice blog site by the way.
Anyway, after a full day of keeping a close eye on things, it would
seem as though making this relatively minor change has made a
noticable increase in performance, or at least an increase in
stability whereby the occasional pause while pages postback is gone.
I can't really explain it because the second computer really isn't
taking that much of a load off the first, but for some reason people
notice it, and so do I.
Again, to anyone who cares: I only store three session variables for
each person logged in: their unique logon name, unique ID number, and
a boolean value I need all the time. That's it. I do reference at
least two of these session variables on nearly every single page,
though. I assign their values to local private variables upon
page_load(). Simply moving the state server service to another
machine on the same network segment seems to have added a small
performance gain to the overall website. A small but perceptable
improvement in "snappiness" and no more slight pauses between
postbacks is a big leap in the eyes of users, so I'm happy. I'll keep
a close watch as the days and weeks go by. The state server machines
does seem to be keeping the sessions under control -- the memory, cpu,
and active sessions never gets out of hand.
Oh, and Scott -- I wouldn't hack that big sign-post either if I were
you <wink, wink>. Of course, the movie "L.A. Story" comes to mind...
Scott Allen <bitmask@[nospam].fred.net> wrote in message news:<o1********************************@4ax.com>. ..
Hi GeekBoy:

The answer is always - it depends. The answer depends on how much data
you keep in session, the type of data you keep in session, and how
performant those types are at serializing themselves into session
state, etc. etc.

You have the right approach - you have to test and take benchmarks and
measure. What might not be a noticable impact for you could be a
signifigant performance drop for someone else's application.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On 18 Oct 2004 07:34:16 -0700, ge*********@yahoo.com (GeekBoy) wrote:
I recognize that -- my question was more: What kind of performance
change will you see when you move the State Server off of the web
server onto a different dedicated computer?

Nov 18 '05 #8
I'm trying hard to avoid it but it sure is tempting!! :)

--
Scott
http://www.OdeToCode.com/blogs/scott/

Oh, and Scott -- I wouldn't hack that big sign-post either if I were
you <wink, wink>. Of course, the movie "L.A. Story" comes to mind...


Nov 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Victor Marquez | last post: by
6 posts views Thread by tshad | last post: by
4 posts views Thread by archana | last post: by
reply views Thread by Med | last post: by
2 posts views Thread by =?Utf-8?B?TUNN?= | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.