I was hoping someone could validate my assumptions before I recommend that my client upgrade from a 30/mo to a 80/mo hosting package.
Site: the site is a custom ASP.NET ecommerce site. the shopping carts are stored in the inproc session.
Problem during busy seasons like we are having now, users are frequently losing their shopping carts and their FormsAuthentication Login information.
Solution I wanted to migrate the site to use a SQL Server Session state. My assumptions are that the customers are losing their shopping carts because the InProc sessions are recycling more frequently then their 20 minute timeout, due to load. Will moving the Session to SQL Server or a Session State Server allow customer to store their Shopping Cart Session without the recycle, If so, can once their will I have any issues if I increase the Session timeout to say 40 or 60 minutes
Using the SQL Session state means that sessions should survive a recycle of IIS, (but not a recycle of SQL Server if you use the default script which creates the session database in the tempdb).
There is a script available from the Microsoft website which creates a permanent session state db. I would recommend using that one instead (See here).
So, to basically answer your question. Yes, the SQL Session state will help. You might want to consider also using the out-of-proc state server to test your theory.
Also, as a co-worker has just reminded me, make sure anything you store in the session is marked as serializable before migrating, otherwise you will run into problems.
Could you just add some RAM to the box? That might help and would likely be cheaper and simpler than moving the session to SQL Server. Of course, it would only be a stopgap, but if it saved them $50/mo for a few years it's probably worthwhile.
You might also check the code to see if some other data is left in the session for much longer than necessary.
The assumptions sound reasonable to me. might also want to look at the settings on the AppPool and try to figure out why its recycling. Maybe all you need to do is change those (if you can).
Related
Our asp.net web application restarts randomly and kicks off users while they are filling a big batch process form.
- the users have to re logging and fill everything afresh
- so keeping in mind that the application/session restarts randomly - which is the most appropriate technology to use for state management - session state (with MS-SQ L server) or asp.net cache ?
You need to configure something other than InProc for your Asp.Net session state provider. What you use depends on how durable the session data needs to be. The session state service is fine but if it does down it will still affect your application like InProc does today. Using a database is the most durable method, although this costs some performance.
You'll have to try and test which one is most appropriate for your needs.
You might also want to figure out why your app is crashing and fix it. I'm assuming its not a scheduled recycle as you said it was random. Recycling is really a Band-Aid for a badly behaving application.
I am building a web site for a sports club. The club is not interested in moving their hosting to a different web host, so I'm stuck with the current host. I deployed the new web application to the host, but after a few hours of testing it became obvious something was acting weird with regards to logins and the session state.
Whenever I spent more than 10 minutes idle, all of a sudden my MVC Verification Tokens would stop decrypting. I went into IIS and set the machine key to a static value, and this problem went away, but it became obvious that they had the ASP.NET idle timeout setting set to 10 minutes. Which means that every 10 minutes InProc session data would be destroyed if there was no activity on the site. I filed a support ticket with the host, but they are unwilling to change that setting for me on my app pool, stating "The setting can't be changed on the server at this time as increasing this could affect the performance off(sic) the server".
The club is somewhat small, at most 500 members of the club and very few of the members will be accessing the site often, so I can pretty much guarantee that the 10 minute timeout will be happening multiple times a day, and I have session timeouts set to 60 minutes, so it won't be a good idea to have the site clear sessions if the sole user of the site at a given time is idle for 10 minutes.
My first thought was to use SQL session storage. I've never used it, but I know it exists. However, one caveat that exists is that we are limited to 350mb of SQL storage. While this is probably more than the site will need right now, I imagine down the line we might come close to hitting the limit. I don't anticipate storing much data in the session, only a few things when interacting with paypal and shopping carts (maybe a system message here or there as well), so perhaps this isn't a huge concern?
We do have unlimited disk space, so another alternative I thought about was to perhaps write a custom disk-based session storage solution. Is there any reason this might not be a better idea than SQL?
And finally, I had a totally off-the-wall "oh god I can't believe I'm thinking about doing this" idea, which would be to have an AJAX call on every page periodically (say, every 8 minutes) "ping" a non-cached lightweight MVC action just to keep the server alive. This would probably work, I think, except for the one scenario where someone:
goes to the shopping page and creates a cart
gets transferred to paypal
spends 10+ minutes on the paypal screen for whatever reason while nobody else is on the site
comes back to see their cart disappear.
In this instance I might just move carts to the database anyway.
So... thoughts, comments, suggestions? I'm really frustrated about the host not letting me change this setting and my first instinct would be to find another host, but as I said before, the club has some strange attachment to the host and doesn't want to move somewhere else.
Thanks in advance!
A few thoughts:
On the problem: It's common for sessions to be 'lost' on Load Balancing systems. This could possibly be fixed by moving to a single designated server (if the hosting company isn't doing this now and provides the option
Cookie sessions: If you're using .Net Membership, you can change the login process to use cookies. This comes with the obvious some users dont allow cookies pitfall. Again, a consideration. Currently working on a school site where they want users to remain logged in.
** With Cookies your Login is stable, but your sessions will not be any better kept. So you're out of luck carrying much to count on in the Session State.
The end result is that you can track users by IP or Cookie, but unless this is a fixable Load Balancing problem, you're heading toward a Session-less application.
I couldn't find anything about this online so I thought I'd ask here. Do any of you have issues with sessions just randomly clearing on a Windows 2008 Server environment? This problem is completely random and very unpredictable. I have no code that clears sessions except on logout, and not quite sure what could be causing it (well, I have ideas...)
My host, who I've been with for many years (and never had a problem with) is telling me that Windows 2003 is better at managing session variables and that I will likely be rid of this session clearing issue if I were to move to a 2003 Server environment. Thing is, I'm already set up and running on IIS 7 with the URL Rewrite module and I'd rather not move or reconfigure URL rewriting. Tech support says the App Pool I am running on is configured properly. My session timeout is set to 60 minutes in Web.config and my host tells me that session timeout is set to 60 minutes for my domain.
I could optionally go with an Azure AppFabric Cache for sessions but I'd rather not pay an extra $50 a month--it's a pretty small and low income site. I'm currently using a SQL Azure database but from what I hear, database sessions are not ideal on SQL Azure.
Thoughts?
Are you modifying any files in the web site?
Changes to the folder or file structure of the web site often triggers an app pool recycling, resetting sessions. The work-around is to use a durable session store like the SQL Server Session State provider.
Most likely answer is your app pool is recycling on you for some reason or another which will dump your in process session every time. Proximate causes can be lots of things, especially if app pools are shared. An easy way to see if your app pool is getting dumped is to take advantage of asp.net heartbeat monitoring, it could be configured to email you when these events occur.
I'm running several ASP.NET web sites with InProc session state and I would like to retrieve the number of active sessions per web site and hopefully any details around each session (eg client connection details).
My end goal is to be able to see who is connected to the web site so that I can notify them when deploying an update.
Is there any way to do this in .NET without resorting to SQL session state? I looked at Microsoft.Web.Administration but couldn't find a way to do it. And the "Sessions Active" performance counter in perfmon just gives the total sessions for the whole server (as well as not giving any metadata about the sessions).
EDIT: In my tests with performance counters I tested with total Sessions Active when I should have tested with the instance of Sessions Active for my web site. This gets me a little closer but I'd still like to actually retrieve the session information for the web site if possible.
Session is a concept, not an actuality. You can use the asp.net global.asax pseudo events for session start/end to track this concept but it will still only be an approximation. I think your best bet is to flip on your "maintenance in progress" flag and put something in the request pipeline that handles it for all incoming requests.
Not sure how/what you would do with this but I think you're going to be rolling some custom code here.
I'm really asking this by proxy, another team at work has had a change request from our customer.
The problem is that our customer doesn't want their employees to login with one user more than one at the same time. That they are getting locked out and sharing logins.
Since this is on a web farm, what would be the best way to tackle this issue?
Wouldn't caching to the database cause performance issues?
You could look at using a distributed cache system like memcached
It would solve this problem pretty well (it's MUCH faster than a database), and is also excellent for caching pretty much anything else too
It's just a cost of doing business.
Yes, caching to a database is slower than caching on your webserver. But you've got to store that state information in a centralized location, otherwise one webserver isn't going to know what users are logged into another.
Assumption: You're trying to prevent multiple concurrent log-ins by a single user.
A database operation at login and logout won't cause a performance problem.
If you are using a caching proxy, that will cause a problem:
a user will log out, but won't be able to log back in until the logout reaches the cache
Your biggest potential problem might be:
if the app/box crashes without a chance for the user to log out, the user's state in the database will remain "logged in".
It depends on how the authentication is done. If you store the last successful login datetime (whatever the backend), so maybe you can change the schema to store a flag "logged_in" and that won't involve an extra performance cost. (ok, it's not clean at all)