I am using Symfony ( current version 2.6.4 ) whenever I want to check if a user is loggedin ( I am also using FOSUserBundle ) I use $user = $this->getUser(); in my controller which works out just fine but if I open 10 links in 1 second this query is repeated for all 10 pages in that second, not so ideal in my option. So my question is, is there a way to cache this query for say 60 seconds and is it even advisable, will it affect new registrations or something. I am using APC as my doctrine cache but if someone knows the answer please also tell us how to use other ways incase other people also wonder how to do this. Thanks.
To start with, sql databases do a good job of automatically caching queries. So while there is some overhead in composing and sending the query to the server, the server itself will respond very quickly. You won't save much be adding another cache.
Should you still try and optimize? In your example of 10 requests per second one assumes that the requests are actually doing something besides getting the user. It's up to you to decide if caching the query will actually speed things up. In most cases the answer will be no. Trying to save every possible microsecond is called premature optimization and is something to avoid.
Having said that, it's worthwhile to look at what the security system is doing. Selected user information is stored in the session. You can use the debug profile bar to look at it. For each request, the security system pulls the user out of the session and then calls $user = $userProvider->refreshUser($user); By default, refreshUser is what causes the database to be queried.
You can easily plug in your own user provider (http://symfony.com/doc/current/cookbook/security/custom_provider.html) which just returns $user. No database interaction at all. Of course if the user's database information does change then they will need to log out and then log back in to see the changes. Or do something else to trigger a real refresh. But for many apps, not refreshing at all will work just fine.
It would also be easy enough to put a time stamp into the session. Your refreshUser method could then use the time stamp to decide if a refresh was actually needed.
So it's easy enough to eliminate the query and actually worthwhile just as a learning experience. Security is one of the more complicated components. The more you understand it the better off you will be. Customizing a user provider is one of the easier things to do.
I just saw your comment about the OAuthBundle. I have not used the bundle in awhile. Implemented my own but I'm surprised that it's hitting the oauth server on each request. If it is then this would in fact be a good use case for overriding the user provider. But I'd be surprised if it was really doing that just for user information.
Related
Problem description
I have an ASP.NET app in which the users have different rights, and are logged in through Facebook. The app includes (among other things) filling out some forms. Some users have access to forms others don't. The forms can sometimes require some searching in books and/or on the internet before being able to submit them.
As such, we're having problems with session time-outs (it seemed), where users would be met with "Not authorized to see this page/form" after doing research somewhere else.
Attempted solutions
I've created a log function that logs the state of a handful of variables on strategic points in the application. I've pinpointed the problem to the fact that the Session variable "UserRole" is null when the problem occurs.
Relogging
The obvious solution is: "Have you tried relogging?" - which should reset the session and allow the user back to the form they want. On logout, I use
Session.Clear();
Session.RemoveAll();
and I create a new session with relevant variables (including UserRole) on login. This doesn't help, though.
Keeping session alive
One way to do it is just increase the standard 20-minute Session length to an arbitrary, higher number (say 2 hours). Although that could be viable during beta (there are only around 5 users right now), it is not a viable solution in the long haul as the server would have to keep the Session objects from many users for longer time, exponentially increasing server demands.
Instead, I created a 'dummy' .ashx handler "RefreshSession.ashx", that can recieve a POST request and return "200" statuscode. I then created a jQuery function in the shared part of the app (that all the pages use) that calls this handler every 10 minutes in order to refresh the session as long as the tab is open in the browser. I've checked the network traffic, and it works as intended, calling the handler even if the window is minimized or the user is viewing another tab. This did not solve the problem either.
A caveat
When one of the users encounter the problem, they call me or my programming partner up. Of course, we go and see if we get the same issue. We all have the same (admin) rights. The 'funny' thing is that we see the exact same error on the same subpage - even if we haven't had any contact with the application for days.
The problem will 'fix itself' (i.e. let users with proper role back on the subpage) after a while, but not even republishing the app to the server will reset it manually.
Therefore, it seems to not be a simpel session error as supposed from the "UserRole" session variable being null after 15-20 minutes of inactivity. It seems to be saved somewhere internally in the server state.
My problem is, that I now have no idea where to look and how to progress. I was hoping that someone here might have an idea for a solution, or at least be able to point me in the right direction? :-)
Thank you all for your time, it is much appreciated.
Based on MaCron's comment to the question, we decided to keep the information in the user's cookies instead of the session variables. Everything seemed to point to us having exactly that issue, and deadlines being deadlines and with me not being able to figure out how to disable the synchronization of worker processes, this seemed to be a feasible and comparatively easy fix.
I am searching to find a way to read and write on session data but with out having the HttpContext. Current.
Why I won to do that ? because I wish to make some action with the user Session after the page have been close and unloaded.
For example, a user load and see a page, then I create a thread to make some action and let user go. Inside this thread I like to read the session data, but in this case HttpContext . Current is not exist any more.
So is there a way to read Session Data knowing just the session id.
I store my session inside an SQL server, and I see them. its there on table ASPStateTempSessions :)
How can I read them "offline" and manipulate them ?
Thank you in advanced.,
Still not quite clear why you might want to do that but you might not actually need to do it on Session_End(). At that point, it may be too late for you to work with the session data anyway (I've read some articles before about this). What might be a better solution is to actually attempt to work on the session data when your application actually has the context.
For example:
There's nothing to stop your application creating an asynchronous request on a new thread in the background (or even a different application, such as a Windows Service, for instance) when the specific session variable that you want is updated or has been set. This way, your application will be able to access the current HttpContext as well as all of the session data.
Not sure if this helps, but it was worth a shot ;)
Richard.
I may be a little late but...
Today I found about the:
System.Web.HttpRuntime.Cache
I know is not the same that a session but I think it's much better alternative that db.
Regards.
If you cache data from your database in ASP.NET session then you will speed up subsequent requests for that data (note: depending on the serialization/deserialization cost of the data concerned), at the expense of memory load in IIS.
(OK, this is probably a simplification of the reality of the situation - feel free to correct or refine my statement above)
Do you use any rules (simple rules of thumb or otherwise) to decide when it is appropriate to cache in Session?
Update
Can use of Session for storing read-only data without very well thought out rationale simply be considered another case of Premature Optimization? (and therefore, bad)
Keep in mind with caching in session if you use the InProc mode, you are limiting your scalability unless your code will go back to the DB when the session is empty. You will be forced to use a single server or pin your user to a particular server.
If your using Session State Server this doesn't apply, and if your using SQL to store session state then using session for caching is pointless.
Edit
Any advice around this topic is subject to your specific environment. As you stated, a very complex sql query might benefit from being cached even when using SQL Session State. I think the most important thing is first make your application perform the functions and achieve the business requirements. Then go back and test and optimize the application to handle the load you expect.
Edit 2
Based on your update no I don't think this is true. In one of my ASP.Net Applications I am using session state to store a complex object model that the user is then manipulating and modifying. We are using AJAX and so we have a lot of short communication to server as user updates the object. Keeping the object in session was done as a convience. The object performs a lot of customized calculations to generate different data points, so doing this on the server was ideal as opposed to trying to replicate the code in the servr and in javascript. Also keeping it in session lets us have an undo function very easily.
And Yes I know we sacrificed scalability, but I welcome the day when I sit down with my boss and explain we have a problem because we have too many users (And I know he would too).
So I think the question is why are you storing data in session is it for convience and to provide access to transient data while the user is logged in? That is different then storing it there for caching. One thing to remeber with caching is how are you going to flush the cache? How do you invalidate it? I don't session state is built to handle this.
Edit 3
Back at it well read only data, user specific, expensive to load from DB, go ahead cache it in session. You can write your code so if it's not in session then you hit the DB. Have a nice little helper class that does this hidding it from your web app that your even using session and you should be good. Nice thing about hidding where you store it from your web if you find you run into issues you only have one place to change it.
Given that it is very hard to guarantee that data in a session gets cleared up in a reasonable time frame, I would be very wary of cashing anything more than the odd integer there. When you get up to a large scale you will either hit memory issues or have all your users get session time out errors. Remember that unlike the Cache object sessions don't get killed off when memory is low.
Also as Josh says if you go to multiple servers and need to use either a Database or Session State Server your session object will need to be serialisable. In this case the cost of serialising and de serialising is likely to be worse than the cost of a well optimized query.
Weird problem here, we're running a few mixed environment web applications, that use Windows or Forms authentication depending on where the user comes from.
I'm curious how everyone else might be handling expired sessions to avoid the errors you would get from someone leaving an idle session open for too long and then trying to resume work, mainly looking for best practices on the subject.
Any suggestions or opinions would be greatly appreciated.
Thanks,
I'm not sure how your authentication method affects session timeouts, the mechanism they use to get in shouldn't affect how long they can stay in.
Generally speaking, if someone does have an expired session, you can add code to check to see if their session is active. If it isn't, just redirect them to a login page, or display some other friendly text.
Basically something like:
if (Session.IsNewSession)
Response.Redirect("login.aspx");
Don't store unnecessary information on the session.
If you are storing something you can reload, have the appropriate code that will reload it if it wasn't found in the session
Consider if some processes are meant to be handled in long periods of time, in which case save intermediate info to the database.
If the user is doing a process that uses the session, and the data is missing, take them to step 1 (not much you can do about it, if you don't have the info elsewhere).
I recently came across a ASP 1.1 web application that put a whole heap of stuff in the session variable - including all the DB data objects and even the DB connection object. It ends up being huge. When the web session times out (four hours after the user has finished using the application) sometimes their database transactions get rolled back. I'm assuming this is because the DB connection is not being closed properly when IIS kills the session.
Anyway, my question is what should be in the session variable? Clearly some things need to be in there. The user selects which plan they want to edit on the main screen, so the plan id goes into the session variable. Is it better to try and reduce the load on the DB by storing all the details about the user (and their manager etc.) and the plan they are editing in the session variable or should I try to minimise the stuff in the session variable and query the DB for everything I need in the Page_Load event?
This is pretty hard to answer because it's so application-specific, but here are a few guidelines I use:
Put as little as possible in the session.
User-specific selections that should only last during a given visit are a good choice
often, variables that need to be accessible to multiple pages throughout the user's visit to your site (to avoid passing them from page to page) are also good to put in the session.
From what little you've said about your application, I'd probably select your data from the db and try to find ways to minimize the impact of those queries instead of loading down the session.
Do not put database connection information in the session.
As far as caching, I'd avoid using the session for caching if possible -- you'll run into issues where someone else changes the data a user is using, plus you can't share the cached data between users. Use the ASP.NET Cache, or some other caching utility (like Memcached or Velocity).
As far as what should go in the session, anything that applies to all browser windows a user has open to your site (login, security settings, etc.) should be in the session. Things like what object is being viewed/edited should really be GET/POST variables passed around between the screens so a user can use multiple browser windows to work with your application (unless you'd like to prevent that).
DO NOT put UI objects in session.
beyond that, i'd say it varies. too much in session can slow you down if you aren't using the in process session because you are going to be serializing a lot + the speed of the provider. Cache and Session should be used sparingly and carefully. Don't just put in session because you can or is convenient. Sit down and analyze if it makes sense.
Ideally, the session in ASP should store the least amount of data that you can get away with. Storing a reference to any object that is holding system resources open (particularly a database connection) is a definite scalability killer. Also, storing uncommitted data in a session variable is just a bad idea in most cases. Overall it sounds like the current implementation is abusively using session objects to try and simulate a stateful application in a supposedly stateless environment.
Although it is much maligned, the ASP.NET model of managing state automatically through hidden fields should really eliminate the majority of the need to keep anything in session variables.
My rule of thumb is that the more scalable (in terms of users/hits) that the app needs to be, the less you can get away with using session state. There is, however, a trade-off. For web applications where the user is repeatedly accessing the same data and typically has a fairly long session per use of the site, some caching (if necessary in session objects) can actually help scalability by reducing the load on the DB server. The idea here is that it is much cheaper and less complex to farm the presentation layer than the back-end DB. Of course, with all things, this advice should be taken in moderation and doesn't apply in all situations, but for a fairly simple in-house CRUD app, it should serve you well.
A very similar question was asked regarding PHP sessions earlier. Basically, Sessions are a great place to store user-specific data that you need to access across several page loads. Sessions are NOT a great place to store database connection references; you'd be better to use some sort of connection pooling software or open/close your connection on each page load. As far as caching data in the session, this depends on how session data is being stored, how much security you need, and whether or not the data is specific to the user. A better bet would be to use something else for caching data.
storing navigation cues in sessions is tricky. The same user can have multiple windows open and then changes get propagated in a confusing manner. DB connections should definitely not be stored. ASP.NET maintains the connection pool for you, no need to resort to your own sorcery. If you need to cache stuff for short periods and the data set size is relatively small, look into ViewState as a possible option (at the cost of loading more bulk onto the page size)
A: Data that is only relative to one user. IE: a username, a user ID. At most an object representing a user. Sometimes URL-relative data (like where to take somebody) or an error message stack are useful to push into the session.
If you want to share stuff potentially between different users, use the Application store or the Cache. They're far superior.
Stephen,
Do you work for a company that starts with "I", that has a website that starts with "BC"? That sounds exactly like what I did when I first started developing in .net (and was young and stupid) -- I crammed everything I could think of in session and application. Needless to say, that was double-plus ungood.
In general, eschew session as much as possible. Certainly, non-serializable objects shouldn't be stored there (database connections and such), but even big, serializable objects shouldn't be either. You just don't want the overhead.
I would always keep very little information in session. Sessions use server memory resources which is expensive. Saving too many values in session increases the load on server and eventualy the performance of the site will go down. When you use load balance servers, usage of session can run into problems. So what I do is use minimal or no sessions, use cookies if the information is not very critical, use hidden fields more and database sessions.