Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Persistence in WebParts
Message
General information
Forum:
ASP.NET
Category:
Class design
Environment versions
Environment:
C# 2.0
Database:
MS SQL Server
Miscellaneous
Thread ID:
01146511
Message ID:
01147829
Views:
29
Ok, many thanks Rick. My leaning was to State Server unless there was an overwhelming reason to use SQL. Around here though, we like to torment the users with dropped InProc sessions. :-)

Bill
>
>I use StateServer. Sql Server is still significantly slower than StateServer, so unless there's a real pressing need to log the state data I don't use SQL Server. Never had a problem with State Server although I suppose it's possible in a shared environment for that service to go down.
>
>+++ Rick ---
>
>
>
>
>>
>>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.
Previous
Reply
Map
View

Click here to load this message in the networking platform