I need more information on new feature in ASP.Net 4.0 Shrinking Session State.
My question is I am using session-state provider that stores data in a Microsoft SQL Server database. If I add compressionEnabled="true" key in web.config file as shown below and not do any code change, will application performance improve. How to check whether compression of sessions are happening and stored in SQL Server. Can any one share any sample code to implement and test this.
<sessionState
mode="SqlServer"
sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
allowCustomSqlDatabase="true"
compressionEnabled="true"
/>
Once you enable compression, session data will be GZip compressed when you use a state server or SQL server but will cost additional CPU cycles on your web server to perform the compression/decompression. This will result in smaller data being transmitted over the wire which will improve performance. Notice that while this reduces the actual session data it is still considered as bad practice to store big amounts of data into the session.
Related
I'm having problems with an ASP.NET application that I need to web-farm, however just logging into my application takes at about 15 seconds
I did a little experiment where I created a non-web farmed version of my application and then used INPROC session state instead, and the login time is immediate. In this test instance, I'm running SQL Express on the same machine.
I know session state on SQL server is slower, but there is no way it should be THIS slower. Any suggestions on how to track down the issue?
This is my session state:
<sessionState mode="SQLServer" timeout="60" sqlConnectionString="Data Source=localhost;Integrated Security=SSPI;" sqlCommandTimeout="30" cookieless="false" useHostingIdentity="False" regenerateExpiredSessionId="True" />
I've tried both using a username password as well as integrated security.
Relational databases are Atomic (ACID), so give pretty poor performance when everyone is hitting the same table (ASPStateTempSessions).
We had the same problem as used the SessionState mode instead, we started the ASPNet State Service on the load balancer and used that. Much better throughput.
<sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" cookieless="false" timeout="60" />
Your question spans a wide area -
Code: What things you are pushing into the session matters a lot. If you are storing large blobs etc, serialization/deserialization happens every time session data is stored and read from the database. Can you parse the data being stored and try to find out average size? I have seen business applications storing 1mb to 2mb data on sql server with thousands of users connected but then underlying hardware was capable enough to support the throughput.
Infrastructure: How much RAM do you have on your machine? Can you try running sql trace on your aspstate database to see how many connections are coming in and how long it takes to execute the query? The problem may not be on the database end, it might be your application trying to do something when storing session information.
SQL Server session storage is not this slow, on my machine with 8gig ram and asp.net application running through visual studio (IIS Express) it takes merely a second to connect and launch the application.
The best thing you can do (if your application permits) is to completely avoid a session storage backend. If the session data fits in the HTTP headers themselves (which usally does) you can have it encoded and move back and forth with the requests themselves as cookies.
Plus most implementations of session state provider are "blocking" so you cannot have concurrent requests for the same session, turning into a huge bottleneck.
This article points to a JWT based drop-in session state provider:
http://www.drupalonwindows.com/en/content/aspnet-session-state-scaling-and-performance-issues
i want to know where a session is stored when i set it in asp.net application. Does it consume RAM or hard disk space?
Actually, i save a datatable into a session variable. I save it into session because calculation of the datatable takes long time. In order not to calculate the datatable again, i get it from the session.
But i am curious about the time when the datatable will grow much larger than now. Will it stuck the ISS?
Thanks
Session state in ASP.NET is by default stored in process memory (which is RAM).
You can change this in web.config by altering the values of the configuration/system.web/sessionState element:
<configuration>
<system.web>
<sessionState mode="...">
</system.web>
</configuration>
The available options are:
InProc (default)
StateServer - will store in a seperate process which can be on a seperate computer
Off
SqlServer - will store state information in a sql server database
Custom - allows you to provide your own session store
Depending on how you configure the Session in your Web.Config, the Session can be stored In-Memory, Asp.NET State Server, Sql Server.
By default, the session is stored in-memory, which means the Ram. If the data-table gets large and there are a number of concurrent users, you may get an exception. Depends on how many users are accessing the system concurrently, what is the Ram on your system etc.
Session state can be stored in different places that you can choose. Here's a good explanation on MSDN
The default is in memory on the server where you web application runs, so if your session grows too large you will indeed have ram/paging problems.
But why session? Is the data in the datatable user-specific? Otherwise Cache would be more appropriate.
If you are using InProc session, then it will be stored in memory. So if you have enough memory it will be in memory. Once you hit your limit look forward to it paging out to disk.
You can also use out of process session storage like the SQL server. This is configurable in the web.config. Note that you will need to have a database configured for it. You can also check out MSDN to read up on the storage types.
Old link above, but still partially useful. Another quick look and I'm found a better link that goes more into detail.
The typical InProc session state is stored in memory of the web server.
like the title shows I want to know what is the difference between "InProc" & "stateServer" mode in SessionState on ASP.NET.
Thanks
In InProc mode, a live Session object is stored in RAM in the ASP.NET worker process (aspnet_wp.exe). It is usually the fastest, but more session data means the more memory is used on the web server, and that can affect performance.
In StateServer mode, each session is converted to XML (serialized) and stored in memory in a separate process (aspnet_state.exe). This state Server can run on another machine.
ASP.NET Session State FAQ
This MSDN article covers SessionState in detail.
Off - Used to disable sessions on website.
InProc - Sessions are stored inside of application's process on web server. Depending of IIS version used that could be aspnet_wp.exe or w3wp.exe.
StateServer - Sessions are stored using State Server windows service.
SQLServer - SQL Server database is used to store sessions' data
Custom - Manage session state using custom session state provider. Storage could be anything you implement in provider.
To specify session state mode in web.config, select one of these values for sessionState mode parameter:
In web.config file, <sessionState> element is located under <configuration>, <system.web> element.
Is there any way to retrieve the SSL session Id serverside in asp.net?
the short answer is no. This is an intentional limitation of IIS, so as to prevent people from taking a dependency on something that isn't dependable.
Out on the market, you will find various hardware load-balancers that will offer features like server persistence based on SSL Session ID, but they don't work very well because SSL renegotiation can happen at any time. In Internet Explorer 8, for example, a new SSL session is negotiated for every tab that is opened to a web site. You can expect similar behaviour from other multi-process browsers. So, I must stress that you should not use SSL Session ID for any kind of user identification purposes.
That said -- If you really need the SSL Session ID information for some specialized task, I recommend using Apache, mod_ssl and mod_proxy as a front-end to your IIS system. With a bit of fiddling, you could coerce mod_ssl into giving you the session ID, which you could then add to a proxied request to your IIS server as a query string parameter.... or you could store it in a database.
Tim,
Are you really "just" trying to retrieve the Session ID string or do you maybe lose all session information when switching to SSL? this would be a quite common problem, because the session on serverside is lost when using "InProc" session storage, and the session cookie on the client might be lost when not stored in a common domain.
Therefore, you should switch to state server or sql server session management in Web.config file, for example:
<sessionState mode="SQLServer"
cookieless="true"
regenerateExpiredSessionId="true"
timeout="30"
sqlConnectionString="Data Source=MySqlServer;Integrated Security=SSPI;"
stateNetworkTimeout="30" />
Beside that, I don't really know why you shouldn't be able to retrieve HttpContext.Current.Session.SessionID also in SSL mode as well.
Some MSDN Links:
MSDN: HttpSessionState.SessionID Property
MSDN: ASP.NET Session State Overview
Maybe this helps somehow.
Best regards
How Can I persist a User-Specific data for an ASP.Net application.
I tried Session Variable - Not good when the worker process recycles.
I need something that can be accessed GLOBALLY by any class of my application.
Advice most welcome.
I tried to utilize asp.net session State Server but I got some DLLs crashing because they are Unserializable.
Is there any other way to have a persistent variable across the application?
ASP.NET session state can be configured to persist to a database.
Here is a tutorial on how to set that up.
Store Data in a Database (such as SQL Server).
You should use Session. You can access session state globally in a class like this...
HttpContext.Current.Session
To avoid losing sessions by the worker process recycling, use StateServer mode.
You can change the Session State Server to not be in process which will make it far more stable and also seperate it from the worker process (You'll need to be able to start the Asp.NET State Service on the server if it's not already running)
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>
Also if you need to share it across applications in the same domain you should be able to give them the same machine key
Theres nothing you can really do about the process recycling. If you use the Cache smartly to retain information in a more global sense but you still have the same worker process limitation.
I try and design my app in a n-tier setup with business entity objects. The factory methods for my objects use the cache kind of like a lazy instantation pattern. If its in the cahce, pull it. If not, put it into the cache for next time.
i.e
MyAppsNameSpace.MyBusinessLayerNameSpace.MyObject.GetObject(objectID)
now when this returns my object, it may be from the cache or may not, if the object is under high usage then it will be probably be cached.
This can be used throughout your entire app and because the caching mechanism is maintained centrally you dont really have to worry about it.
You could use the Profile Provider with a SQL database as your backing store.
See this MSDN Article
If you lose data when the worker process recycles then you should stop using the InProc persistance mode for the Session. Use StateServer or SQL Server. Ultimately you could build your own session persistance module if neither satisfies you.