When building an ASP.NET MVC application with a goal of high availability, is it a good practice to keep the session state on the SQL Server, if there is no state server available?
The point here realy is that you have 2-3 webservers like you mentioned in the comment to Craigs answer.
One way is to use SQL-server sessionstate which has its own problems http://idunno.org/articles/277.aspx.
If you have this one SQL-Server I would be carefull, because the DB for sessionstate will put heavy load on it. Each request will write to the db.
We use 2 webservers and a Loadbalancer that has sticky sessions. If your first request ends up in server 1 then all your requests are handled by server 1. (Its a bit more sophisticated but you get the idea.)
This might not allways be the best solution, but at least on our site (its a shop where user typically stay 20-30minutes) it works well. We use only little SessionState and have most of the userspecific stuff stored by the ProfileSystem. But I guess the ProfileSystem will also fail if requests go to different servers.
I'd suggest AppFabric Caching (f.k.a. Velocity) instead.
Related
In my Rails app, once per user session, I need to have my server send a request to one of our other services to get some data about the user. I only want to make this request once per session because pinging another service every time the user makes a request will significantly slow down our response time. However, I can't store this information in a cookie client-side. This information has some security implications - if the user has the ability to lie to our server about what this piece of information is, they can gain access to data they're not authorized to see.
So what is the best way to cache or store a piece of data associated with a session on the Rails server?
I'm considering using Rails low-level caching, and I think it might even be correct:
Rails.cache.fetch(session.id, expires_in: 12.hours) do
OtherServiceAPI.get_sensitive_data(user.id)
end
I know that Rails often has one canonical way of doing things, though, so I want to be sure there's not a built-in, officially preferred way to associate a piece of data with a session. This question makes it look like there are potential pitfalls using the approach I'm considering as well, although it looks like those concerns may have been made obsolete in newer versions of Rails.
Is there a canonical pattern for what I'm trying to do? Or is the approach I'm considering idiomatic enough?
I'm converting an application from C# WebForms to MVC.
The application gets settings from a centralized location using Web Services. These are settings you would typically find in a Web.Config, but the desire of the company is to store these values in a centralized location for all apps.
Currently, any time you request an application setting, it checks HttpContext.Cache to see if you've already retrieved the settings. If you haven't, it makes the web service call, and stores the settings (100+ objects that are essentially key/values) in the HttpContext.Cache. So the call to get application settings only occurs once.
Should I be looking at another way to do this? I was thinking the settings should just be a REST service call where you pass the key and get a value (the current service is an *.ashx which is really not ideal for exception handling amoung other reasons). But obviously this would result in more web requests. What is considered a best practice here? Is the current method fine and I should just leave the code working the same in the MVC app?
It is better to load all resources in one call:
fewer HTTP requests are better for performance. Http requests can have a latency around 50 ms thus it will take much longer to get all values one by one 50 x 100 = 5000 ms => 5 secs
if the external web service goes down then your application still works because you already downloaded and cached all values
I will keep the current solution if it works and focus on new things instead of rewriting a working code.
How big is the performance penalty switching from the cookieStore to the ActiveRecord SessionStore?
By default Ruby on Rails uses the CookieStore. But it has the disadvantage that the client needs to have its cookies enabled.
Switching to the Active SessionStore seems to solve that problem. I'm considering switching.
I read that performance is worse using the ActiveRecord SessionStore. But what is worse? Will a user notice this, or is it a matter of milliseconds? Anybody has seen benchmark results comparing the 2 options?
Any other reasons (not) to switch to the ActiveRecord SessionStore?
What is worse is that it needs to query a database, which then needs to calculate the answer, rather than going straight to the cookie on the client side.
However is it really that bad? You are correct in that the performance difference is very minuscule in most cases.
Pros:
Affinity-
If your web application ever expands to more than one server, moving your sessions to a database can allow you to run your servers without server affinity.
Security
- Since you only store the session ID on the client side, this reduces the chances of the user manipulating any data via the client side.
Cons
Performance - Instead of querying the database, you can just read the session/cookie data from the client side.
But the AR session store also depends on cookies - it saves the session id there.
As far as I know there is no way to make Rails sessions work with cookies disabled.
What will be the most efficient way to make an ASP.NET MVC application web-farm ready.
Most importantly sharing the current user's information (Context) and (not so important) cached objects such as look-up items (States, Street Types, counties etc.).
I have heard of/read MemCache but haven't seen a simple applicable way (documentation) on how to implement and test it.
Request context
Any request that hits a web farm gets served by an available IIS server. Context gets created there and the whole request gets served by the same server. So context shouldn't be a problem. A request is a stateless execution pipeline so it doesn't need to share data with other servers in any way shape or form. It will be served from the beginning to the end by the same machine.
User information is read from a cookie and processed by the server that serves the request. It depends then if you cache complete user object somewhere.
Session
If you use TempData dictionary you should be aware that it's stored inside Session dictionary. In a server farm that means you should use other means than InProc sessions, because they're not shared between IIS servers across the farm. You should configure other session managers that either use a DB or others (State server etc.).
Cache
When it comes to cache it's a different story. To make it as efficient as possible cache should as well be served. By default it's not. But looking at cache it barely means that when there's no cache it should be read and stored in cache. So if a particular server farm server doesn't have some cache object it would create it. In time all of them would cache some shared publicly used data.
Or... You could use libraries like memcached (as you mentioned it) and take advantage of shared cache. There are several examples on the net how to use it.
But these solutions all bring additional overhead of several things (like network and third process processing and data fetching etc.) if nothing else. So default cache is the fastest and if you explicitly need shared cache then decide for one. Don't share cache unless really necessary.
I want to integrate a shopping cart in my site. The cart should be such that it resets once the user signs out of the application. This can be either achieved via sessions or using the database tables.
What should be prefered out of the above two? Are there any security loop holes if this is handled via sessions?
In the security department, none of the two are prefered over the other. You should understand that both concepts are basically "sessions", but one is handled in the appdomain, the other is handled in the DB-domain.
Appdomain sessions:
Faster (No round-tripping to database)
Not scalable
Prone to concurrency problems on server farms
Sessions will be lost on server restart
Database sessions:
Slower (Roundtrips to the DB for each request)
Easier to scale on serverfarms
Sessions will be kept open on server restarts
You should consider how many users will be using your site. If you are looking at a lot, you are probably going to need multiple servers, in which case the database sessions will be your best bet, if you will stay with a single webserver / database server, then appdomain sessions will do fine.
I don't see why HttpSessions increase your security exposure - if your session is hijacked then presumably so is your DB access.
If you really intend that your user's cart should be transient then clearly your HttpSession is sufficient. Scaling app servers usually have session replication capabilities to deal with individual server failures.
I'm sceptical in the long term that such a volatile cart will always be what you want, I find it very convenient to browse around Amazon and assemble my cart, then just leave it for while. As it's probably not a great deal more work to persist your cart in a DB, I'd probably go for that.
I would use Sessions - no point of clogging up your DB on data that will be destroyed on log out.
Plus, Sessions are quite safe to use.