Session issues on multi processor machine

  • Thread starter Thread starter Shiv Kumar
  • Start date Start date
S

Shiv Kumar

Is there a known problem or caveat with ASP.NET sessions on a multi-processor machine? Are sesions bound to a CPU or are they application wide?

My machine.config is the default and my web.config file has no session specific entries. On my development machine XP I have no problem but on the production server W2K3/dual proc I have issues.
 
My understanding of asp.net worker process and mutiple processors is that each processor runs its dedicated aspnet worker process. And if you are using default config then you are using InProc sessionState. In this case session variables will be local to each of the worker processes.

I would advise you to look into configuration of sessionState in your web.config.. you can either set it up as a StateServer or can store it in SQL Server.



--
Regards,

HD

Is there a known problem or caveat with ASP.NET sessions on a multi-processor machine? Are sesions bound to a CPU or are they application wide?

My machine.config is the default and my web.config file has no session specific entries. On my development machine XP I have no problem but on the production server W2K3/dual proc I have issues.
 
Hermit,

Thanks for your reply.

So it looks like I don't have an option to use the default session state mode (in memory) on a multi-processor machine? If so this goes against the grain doesn't it? I thought the whole idea was about having a choice (which way to go). But it looks like I don't really have a choice. Or did I miss-read your reply.

I'm curious, does anyone else find this to be a problem/limitation?
 
yes the idea is that you have a choice....
check the application pool settings... set the number of worker processes to just one.
have a look at this... this is on Performance Application Pool Settings (for IIS 6.0 win2k3)
http://msdn.microsoft.com/library/d...l/cpconperformanceapplicationpoolsettings.asp

check the processModel on IIS 6.0 win2k3's machine config (to see if its set to a web garden scenario)


check the machine config and your app webconfig...
if you dont have a sessionState Element in your app's web config.. it will use the values from machine.config (not sure what its called in IIS 6.0)

you can just enable one worker process that should start sort out your session issues... but for more information... think we would need to know your app's webconfig <sessionState /> and your machine.config's <sessionState> also the setting for the processModel on your server.

hope this helps...

--

Regards,

HD

PS: If you want to use more than 1 worker processes than you will have to resort to a web garden scenario.. and to make sure data is available to the other worker processes you will have to store in using StateServer or SQLServer
Hermit,

Thanks for your reply.

So it looks like I don't have an option to use the default session state mode (in memory) on a multi-processor machine? If so this goes against the grain doesn't it? I thought the whole idea was about having a choice (which way to go). But it looks like I don't really have a choice. Or did I miss-read your reply.

I'm curious, does anyone else find this to be a problem/limitation?
 
Hermit,

I had already read that article and a whole host of others. :) I do have confirmation that sessions are tied to a worker process (As you rightly said), and as a result (if one is to use multiple worker processes for performance reasons) then one has no choice but to avoid using the InProc mode. This is a real shame in my opinion.

Thank you for your replies.
 
inproc is a good thing.. but again... you want to feel the sun from both sides... its a seperate worker process !!!! so you cant be sharing memory.. first that would be a bad design and second you have a security headache...

so if you are using multiple worker processes and would like to continue to use session state then your choices are StateServer and SqlServer...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetsessionstate.asp

nice article... hope it helps...

--
Regards,

HD

Hermit,

I had already read that article and a whole host of others. :) I do have confirmation that sessions are tied to a worker process (As you rightly said), and as a result (if one is to use multiple worker processes for performance reasons) then one has no choice but to avoid using the InProc mode. This is a real shame in my opinion.

Thank you for your replies.
 
Hermit,

Yes I understand the concept or worker process :) I've been a Windows programmer for 8 years and have been building ISAPI applications for almost as long :)

I still think there is a feeling of "bad design" somewhere in all of this. To me it's a limitation and besides which one now needs a development machine that is similar to the production machines. That's just my point of view by the way.

That's not to say I don't understand the ASP.NET framework better now :)
 
Further, the target machines configuration plays a role since your application may not work because some other application may require multiple worker processes while this one can't use that setting. From my understanding using the worker process model is a machine wide setting.

I can just see issue in the long run between compatibility of applications running on the same box but requiring different configurations either by design or to meet performance requirements etc.

My two cents.
 
true i take your point that target machines config does play an important role... yeah been working ms stuff for a while.. though c++/atl half the time.. and have had my share of dealing with asp/ iis.

in good ol days we only have inetinfo and that did just bout everything.. with i guess ms are going the right way by making sure that if you have a multi proc system and what you would want failover with or without resorting to a web cluster then you make the each process independant.. now all iis does is calling up aspnet isapi to pass the call to aspnet worker process... and since you have multiple process rather than 1 big fat iis... sharing the data can be an issue.. not to forget added issues with marshalling across process boundaries to share the data and protection of data from potential corruption... (reminding me of com days)

i reckon we both can go on and on... it probably would be cheaper to get yourself a multiproc dev server. %>)

--
Regards,

HD

Further, the target machines configuration plays a role since your application may not work because some other application may require multiple worker processes while this one can't use that setting. From my understanding using the worker process model is a machine wide setting.

I can just see issue in the long run between compatibility of applications running on the same box but requiring different configurations either by design or to meet performance requirements etc.

My two cents.
 
and i always had a feeling that people specially from c++ would probably start appreciating .net's beauty after they got used to the constraints imposed by the design... lol
(I did whine and bitch bout it for over 2 years before i could actually do anything... lol used to remind me of java)

--
Regards,

HD

true i take your point that target machines config does play an important role... yeah been working ms stuff for a while.. though c++/atl half the time.. and have had my share of dealing with asp/ iis.

in good ol days we only have inetinfo and that did just bout everything.. with i guess ms are going the right way by making sure that if you have a multi proc system and what you would want failover with or without resorting to a web cluster then you make the each process independant.. now all iis does is calling up aspnet isapi to pass the call to aspnet worker process... and since you have multiple process rather than 1 big fat iis... sharing the data can be an issue.. not to forget added issues with marshalling across process boundaries to share the data and protection of data from potential corruption... (reminding me of com days)

i reckon we both can go on and on... it probably would be cheaper to get yourself a multiproc dev server. %>)

--
Regards,

HD

Further, the target machines configuration plays a role since your application may not work because some other application may require multiple worker processes while this one can't use that setting. From my understanding using the worker process model is a machine wide setting.

I can just see issue in the long run between compatibility of applications running on the same box but requiring different configurations either by design or to meet performance requirements etc.

My two cents.
 
i reckon we both can go on and on... it probably would be cheaper to get yourself a multiproc dev server. %>)

:)

It's cheaper just ranting! But yes, there are some nice features and some not so nice.
 
(I did whine and bitch bout it for over 2 years before i could actually do anything... lol used to remind me of java)

:)
 
lol yeah some nice features... and some i guess will get better.... always optimistic....

see what converted me from a die hard c++ to a c# and .net coder was comments by one of the core contributers to GNOME project (Miguel) year or two back...
http://linuxtoday.com/news_story.php3?ltsn=2002-02-06-011-20-OP-GN-MS

i then tried to think of it from a prespective of next gen of what COM was meant to be. and yes now a days i do concentrate on the differences rather than the similarities
:)

--
Regards,

HD

PS: Once a geek... always a geek

Shiv Kumar said:
i reckon we both can go on and on... it probably would be cheaper to get yourself a multiproc dev server. %>)
Click to expand...

:)

It's cheaper just ranting! But yes, there are some nice features and some not so nice.
 
Interesting article!

On the face of it I like .NET and I like C# as well. I'm a hard core Delphi/ Delphi for .NET programmer (programming exclusively in Delphi for eight years) as a result C# and Delphi (for me) are very similar probably because Anders wrote/invented both :).

The ASP.NET framework is impressive to say the least considering some of the cr** Microsoft has been dishing out in the past. However, having been an ISAPI programmer for 6 years and having built my own framework similar to ASP.NET in many ways, I also see some design issues. Having a framework such as ASP.NET out of the box is by far a whole lot better than having to maintain ones own framework.

I realize it's a matter of learning new tricks. Unfortunately it's also about giving up some nifty old tricks especially since the framework is such that one has no option but to do so.

Besides not all programmer build faulty applications, so who are "they" to decide/force isolation of our applications? lol
 
i know was a very interesting email (article too). What stuck me was that a
person in Miguel's position could see the benefits and had the courage to
stand up for it.... it was then that i forced myself to look deeper into
..net... (considering the fact that he is a *nix person... standing up for
anything even remotely connected to MS is like signing their own death cert.

i wont say i have used delphi a lot... have seen the code while helping
people do ... say remoting or help then use dcom written in delphi... it was
a nightmare.. i would rather go back to c++... lol
what do you mean by cr**... the last thing microsoft came out with was com
before .net... and trust me it was beautiful... yes they extended RPC and
used its mechanism to create their own framework... and it worked too... i
remember some 5 years back me writing my first com component using c++...
took me a while to get it working... even more to get it to work with VB and
ASP but it was indeed sound... the problem was that... with ms programming
you have two main streams... c++ programmers using win32s... mfc and atl and
VB (or other languages using RAD). The performance wasnt the same cause with
say VB.. it used to shield everyone so that they knew nothing bout COM when
they actually wrote a com component... plus you had issues with api access
across languages...

yeah i know.. its all about learning new tricks and sometimes its not easy
to not use the old ways. But imagine... all this time... okay MS did a patch
work and that resulted in a layered system which had so many issues... and
at times it was bad programming by others using MS stuff that gave it a
really really bad name.. plus i guess MS did learn a lot of things.. with
java coming into picture the MS platform was itself at stake... and there
were two options... one make it easier to write code with a better
programming model or continue the path and result in its eventual death...
yes they did excellent job at picking up where java left... and made it
something even Sun cant come closer to.... the best they made it a standard
and published it.... and they invited whole lot of others to write compilers
generating msil....

plus the best frameworks are frameworks that use K.I.S.S methodology... so i
guess that translates to keep it simple.. and give options... different
options...

yeah i used to crib bout not having pointers as a part of managed code...
but again.. pointers are powerful and we have seen it abused over and
over.... (as for isoloation... i have seen in enterprises they dont go for
ms stuff because its not fault tolerant enough... and its not stable
enough... well stablity and being fault tolerant come at a price... yes you
still have to flexibility to use pointers and use the old ways to a great
extent... its just clr will not play a part....
plus MS even showed thats its possible to use ASP.NET without even a proper
webserver... cassini was a good example... one could potentially write their
own thing.. and potentially make changes all the way while using the same
programming model... (imagine you writing your own cassini to serve
asp.net... can write your own way of handling session etc...

--
Regards,

HD

Once a Geek.... Always a Geek
Interesting article!

On the face of it I like .NET and I like C# as well. I'm a hard core Delphi/
Delphi for .NET programmer (programming exclusively in Delphi for eight
years) as a result C# and Delphi (for me) are very similar probably because
Anders wrote/invented both :).

The ASP.NET framework is impressive to say the least considering some of the
cr** Microsoft has been dishing out in the past. However, having been an
ISAPI programmer for 6 years and having built my own framework similar to
ASP.NET in many ways, I also see some design issues. Having a framework such
as ASP.NET out of the box is by far a whole lot better than having to
maintain ones own framework.

I realize it's a matter of learning new tricks. Unfortunately it's also
about giving up some nifty old tricks especially since the framework is such
that one has no option but to do so.

Besides not all programmer build faulty applications, so who are "they" to
decide/force isolation of our applications? lol
 
i wont say i have used delphi a lot... have seen the code while helping
people do ... say remoting or help then use dcom written in delphi... it was
a nightmare.. i would rather go back to c++... lol
Click to expand...

:)
Delphi has all the power of C++ and RAD if you need it. To understand RAD
you need to use Delphi since VB's RAD is not RAD by any shot of the
imagination :). But lets not get into a war here :) I programmed in VB for
years until I laid my eyes on Delphi.

If you like C# just imagine it to be Delphi. There is hardly difference.
what do you mean by cr**... the last thing microsoft came out with was com
before .net... and trust me it was beautiful... yes they extended RPC and
Click to expand...

With Delphi we have a lot more options. COM is just one of the many options,
so unless you've tried other options you won't know which is better right? I
mean if COM was so great then why abandon it? But let not get into that
either :)

..NET looks like a better Java and has more promise than Java, IMO.
 
If you like C# just imagine it to be Delphi. There is hardly difference.

No it is not delphi. Don't try to pass it off as delphi either. Delphi is
pascal. Pascal is not C#. Pascal is an academic language, designed
specifically for instructional purposes. Somewhere along the lines, somebody
decided that this teaching tool could be used in industry. The rules are
entirely different with regard to scoping and variable declaration which
directly impact memory allocation and deallocation. Even C++ builder is not
C++ because the C++ engine is written in pascal - a ton of crap if you ask
me.

Delphi performance cannot be compared to C# performance either. Delphi
performance is a click above visual basic performance. In fact, if you are
going to pass delphi off as anything, pass it off as VB. That is it's level
of competition. It absolutely cannot compete in the big boys game.
Delphi.NET on the other hand is qualified to play with the big boys.

I am qualified to talk about it too because I wrote applications in it for a
couple of years. Absolutely hated it. And I guess I wrote crappy code too.
The languages brings out the worst in me. Anyway, the company I used to work
for switched to C++ because they needed a more powerful platform for their
app. Go figure.

I'll say in all fairness that anjers was responsible for a number of
innovations in delphi which is why he now works for microsoft.
 
And I guess I wrote crappy code too.
You obviously did!
And just because you used it for a few years doesn't make you qualified to
speak with authority either. So before you turn this thread into a language
war I ask that you refrain from adding your unqualified comments here.

I'll let you have the last word if you like :)
 
Hey Alvin, do me a favor, keep your notions to yourself please.
No, I won't do you a favor.
This forum is about not keeping my notions to myself that's why it is
public. You made a blanket statement, i jumped you on it. If you don't like
being jumped, stop making blanket statements - especially when they are far
from true. If you have support for your flawed statements, provide them and
I will jump on those as well, otherwise refrain from them.

I'll always jump in to the middle when I perceive a post to be technically
inaccurate. That stuff don't sit well with me for obvious reasons. I'm not a
warmunger either but thanks for the cute remark. It didn't go unnoticed. I
don't care to justify my technical ability to you either because it doesn't
change the fact that your statements are inaccurate.
 
Back
Top