Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Persistence in WebParts
Message
Information générale
Forum:
ASP.NET
Catégorie:
Conception classe
Versions des environnements
Environment:
C# 2.0
Database:
MS SQL Server
Divers
Thread ID:
01146511
Message ID:
01147585
Vues:
27
Hi Rick,

Completely agreed on the InProc issue and I've told/warned them about this but the response was basically a shrug and "it's been working ok." :-| My monitoring of my exception log indicates differently but when you have no authority to mandate otherwise you just monitor and note it. :-)

Didn't know the performance for State Server could be that different. In that case it might be just as well to use SQL Server for state management.

Which do you use in production?

Bill

>>1) InProc is the fastest since it's in proc. :-) But it's also the most volatile since if anything touches the web folders it can trigger IIS to "restart" the web application which unloads all the state data, so the guy who just spent 20 minutes filling his shopping cart just got it unloaded for no extra fee. :-) I believe some virus scanners have been known to trip the switch that causes IIS to reload the app.
>
>Using InProc in production is pretty much suicide I think, since there are so many things that can trigger a Web app to restart. If there's anything vital in session state - especially user login information it's a big pisser to get 'kicked off' because of lost sessions.
>
>>2) State Server is quite good and is made for this task. It's fast also since, I believe, for the most part it holds state data in memory. But it is isolated from IIS and, AFAIK, could even be on a different server. There's some overhaed of course marshalling the state data back and forth to IIS but I beleive if it's set up properly it's not a lot slower than InProc. It requires objects held in state to be serializable.
>
>It's actually considerably slower than InProc if you really push on it. I don't remember the exact numbers but it was something like 2x slower with SQL being 3-4 times slower (all on a local machine). Once you go off to another machine with shared state the values get slower yet. On the local machine the overhead is in hte marshalling.
>
>However, I also think in most database applications this 'overhead' is usually not too bad unless you have many objects stored. Especially OBJECTS rather than simple values which serialize much quicker and with less data.
William A. Caton III
Software Engineer
MAXIMUS
Atlanta, Ga.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform