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)
Related
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.
Is there a way to see who is currently logged in to a Plone site?
Rationale: I want to make sure not to interfer with users working on content when I restart the instance.
Out-of-the-box, there is no way to see if users are currently using your site, only if they have just been using it. Just tail the instance-Z2.log access logfile.
Note that due to the nature of the HTTP protocol, 'current' users of your site do not maintain a connection, and thus, until they are back again for the next request, there is no accurate way to determine if anyone is using the site.
There are work-arounds, such as using sessions and timeouts, that use recency to estimate how many users are still around. collective.portlet.usertrack is one such approach. Note that such approaches can have a hefty scalability penalty though.
If all you want to do is not inconvenience users during a restart, use a caching frontend and / or a load balancer and more than one instance instead. That way users see cached content or content generated by an instance still up while you restart your first instance.
you can try collective.portlet.usertrack
I am working on a web app in ASP.NET/C# which needs to be scalable to handle the high user load (will probably run in a web farm). Since it will cater to a high number of users, around 1 Million plus, but number of online users would be around 30K-50K. I plan to use caching (provider based), and was wondering:
Is it a good idea to cache ALL users for performance? I plan to cache all other generic data, like settings etc, but how efficient would it be to cache ALL users in memory? If a user changes his/her profile, I will reload only that particular user in cache (having a collection of all the users). Any suggestions on this approach?
Do I need to worry about locking when using this above users cache? Only one editing the profile would be the user himself, that would be one atomic operation, though there will be multiple read oeprations in different threads. So while fetching users from cache, or updating a particualr user, should I use lock?
Thanks
Asif
Putting anything in Global Cache that is only useful to a single user is usually a bad idea and a performance killer. Optimize your database queries, and you will be in much better shape.
As a general rule of thumb you should only keep things in cache that are expensive to get from the database, and more than one user will want to see that information at once. Such as a list of the top 100 products or something. Small amounts of data that are relatively cheap to grab from the database, and that are only useful to a single person should stay where they are.
Caching increases complexity tremendously, and even more so in a web farm. Don't introduce needless complexity unless you absolutely have to. Wait until you have an actual performance problem before trying to solve it.
Caching users is probably a good idea. But it depends on how much data you are going to cache for each user, and the cost of retrieving that data from wherever it is stored.
For locking - can anyone else edit a user's profile (like an admininstrator)? Would that be a common occurrence? If so, you may want to do some locking. Otherwise, if only the user can edit their own stuff, I wouldn't bother.
If not, are there any fundamental limitations of the service that prevent one from being built?
In response to Garys answer. "If you're hosting your app on EC2, it'll be fine"
Even if you're hosting your application on EC2 you should not really use SimpleDB to store session state. It provides an "eventually consistent" guarantee, so if you PUT something there is no guarantee that you will see the item on your next GET.
see: http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/index.html?EventualConsistencySummary.html
This is fine when you want to use simpledb to do indexing on data that does not need to be immediately up to date and can be reconciled later, but in the case of session state, you'd likely want something with ACID guarantees (like SQL Server) as you want to know that once you have committed something you will get it back on the next read.
This obviously depends on your requirements, but most people use session state to store shopping cart items or similar. Your site visitors will soon get upset if things appear to go missing from thier cart, then re-add them and then discover they have added the same item twice when they come to pay.
There's a C# library for working with SDB.
If you want to roll your own, the API, WSDL and other documentation can be found at http://aws.amazon.com/simpledb/#resources.
It's a pretty straight forward API that rides over HTTP. The hardest part is writing the signing code. There's plenty of implementations in other languages.
As for using it for session state, there's a huge speed difference between using SimpleDB from EC2 and anywhere else on the internet. If you're hosting your app on EC2, it'll be fine, otherwise, it'll be brutally slow.
You could base it off this MySQL provider:
http://harry-kimpel.spaces.live.com/Blog/cns!CAA619CB4C4D1B6C!342.entry
I am looking for ways to keep track of simultaneous users within an application. I cannot use IIS logs due to a load balancer that abstracts the users IP address. I am looking for a .NET code based solution or a configuration item, possibly with health monitoring to be able to track the "true" simultaneous user count.
I know that I can monitor the number of sessions, but that isn't really an ideal method to show, as it can be bloated based on the number of sessions with users abandoning their session.
There is a similiar question here: Tools and methods for live-monitoring ASP.NET web applications?
I found an advanced logging tool for debugging and monitoring .NET applications: SmartInspect. But I don't know if it meets your requirements.
What do you mean of "simultaneous users"? Perhaps you should monitor simultaneous TCP connections to your IIS application? Windows Performance Monitor tools should help you there.
Otherwise there is no sure way of telling how many users are using your application right now. If you can monitor number of sessions, then I'd suggest going with that. Just take into account the last modification time of the sessions, so you could get something like "active sessions in the last minute". That should give you a close measurment.
In the end we decided to use ASP.NET Performance counters, as well as generic information from the IIS Logs.
I parsed the information from both sources using the Microsoft Log Parser tool!
You just want to know the number of active users at a particular time? An easy option that omits inactive users as well as most bots would be to register the user as active through a JavaScript AJAX call on page load along with their SessionID. You can then purge old records from the log as you see fit. *Be careful of how you build your table's performance for read/write optimizations. ... just an idea off the top of my head.
We are using an expensive solution which is AVICode but it is great. You can monitor so many thing with that.