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.
Related
I am working on a vendor portal. An owner of a shop will login and in the navigation bar (similar to facebook) I would like the number of items sold to appear INSTANTLY, WITHOUT ANY REFRESH. In facebook, new notifications pop up immediately. I am using sql azure as my database. Is it possible to note a change in the database and INSTANTLY INFORM the user?
Part 2 of my project will consist of a mobile phone app for the vendor. In this app I, too , would like to have the same notification mechanism. In this case, would I be correct if I search on push notifications and apply them?
At the moment my main aim is to solve the problem in paragraph 1. I am able to retrieve the number of notifications, but how on earth is it possible to show the changes INSTANTLY? thank you very much
First you need to define what INSTANT means to you. For some, it means within a second 90% of the time. For others, they would be happy to have a 10-20 second gap on average. And more importantly, you need to understand the implications of your requirements; in other words, is it worth it to have near zero wait time for your business? The more relaxed your requirements, the cheaper it will be to build and the easier it will be to maintain.
You should know that having near-time notification can be very expensive in terms of computing and locking resources. The more you refresh, the more web roundtrips are needed (even if they are minimal in this case). Having data fresh to the second can also be costly to the database because you are potentially creating a high volume of requests, which in turn could affect otherwise good performing requests. For example, if your website runs with 1000 users logged on, you may need 1000 database requests per second (assuming that's your definition of INSTANT), which could in turn create a throttling condition in SQL Azure if not designed properly.
An approach I used in the past, for a similar requirement (although the precision wasn't to the second; more like to the minute) was to load all records from a table in memory in the local website cache. A background thread was locking and refreshing the in memory data for all records in one shot. This allowed us to reduce the database traffic by a factor of a thousand since the data presented on the screen was coming from the local cache and a single database connection was needed to refresh the cache (per web server). Because we had multiple web servers, and we needed the data to be exactly the same on all web servers within a second of each other, we synchronized the requests of all the web servers to refresh the cache every minute. Putting this together took many hours, but it allowed us to build a system that was highly scalable.
The above technique may not work for your requirements, but my point is that the higher the need for fresh data, the more design/engineering work you will need to make sure your system isn't too impacted by the freshness requirement.
Hope this helps.
I build ASP.NET websites (hosted under IIS 6 usually, often with SQL Server backends and forms authentication).
Clients sometimes ask if I can check whether there are people currently browsing (and/or whether there are users currently logged in to) their website at a given moment, usually so the can safely do a deployment (they want a hotfix, for example).
I know the web is basically stateless so I can't be sure whether someone has closed the browser window, but I imagine there'd be some count of not-yet-timed-out sessions or something, and surely logged-in-users...
Is there a standard and/or easy way to check this?
Jakob's answer is correct but does rely on installing and configuring the Membership features.
A crude but simple way of tracking users online would be to store a counter in the Application object. This counter could be incremented/decremented upon their sessions starting and ending. There's an example of this on the MSDN website:
Session-State Events (MSDN Library)
Because the default Session Timeout is 20 minutes the accuracy of this method isn't guaranteed (but then that applies to any web application due to the stateless and disconnected nature of HTTP).
I know this is a pretty old question, but I figured I'd chime in. Why not use Google Analytics and view their real time dashboard? It will require minor code modifications (i.e. a single script import) and will do everything you're looking for...
You may be looking for the Membership.GetNumberOfUsersOnline method, although I'm not sure how reliable it is.
Sessions, suggested by other users, are a basic way of doing things, but are not too reliable. They can also work well in some circumstances, but not in others.
For example, if users are downloading large files or watching videos or listening to the podcasts, they may stay on the same page for hours (unless the requests to the binary data are tracked by ASP.NET too), but are still using your website.
Thus, my suggestion is to use the server logs to detect if the website is currently used by many people. It gives you the ability to:
See what sort of requests are done. It's quite easy to detect humans and crawlers, and with some experience, it's also possible to see if the human is currently doing something critical (such as writing a comment on a website, editing a document, or typing her credit card number and ordering something) or not (such as browsing).
See who is doing those requests. For example, if Google is crawling your website, it is a very bad idea to go offline, unless the search rating doesn't matter for you. On the other hand, if a bot is trying for two hours to crack your website by doing requests to different pages, you can go offline for sure.
Note: if a website has some critical areas (for example, writing this long answer, I would be angry if Stack Overflow goes offline in a few seconds just before I submit my answer), you can also send regular AJAX requests to the server while the user stays on the page. Of course, you must be careful when implementing such feature, and take in account that it will increase the bandwidth used, and will not work if the user has JavaScript disabled).
You can run command netstat and see how many active connection exist to your website ports.
Default port for http is *:80.
Default port for https is *:443.
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 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).
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)