Greetings,
Windows Azure only supports SQL Azure Session State for multiple instances.
I'm thinking what whether storing the objects in session will boost any performance for given scenario below:
Scenario:
I've got MVC Application where it's header and footer are populated from DB. I've created ApplicationController which inherits from controller. This applicationcontroller in turn will be inherited by actual controllers such as Home/Account etc.
I'm thinking of loading all these footer/header value in to session and use the session object for any subsequent requests.
Does anyone know whether this will boost any performance? Only reason I'm asking is that SQL Azure Session would do the same thing i.e. query SQL Azure Session storage for each request?
Thanks.
I would say that right now the amount of performance improvement you get from one option over the other is pretty negligible. The only way to know for sure would be to create some test scenarios.
Having said that, App Fabric Caching is coming out of CTP in less than a month and includes a session provider. If you were willing to use it you'd have two options:
Use the App Fabric Caching session provider and the session technique you've described above and it should be faster than either of the SQL options
Use the cache directly to provide the header and footer information (you'll still need to keep the data in SQL, but you can populate the cache on demand when headers and footers are requested)
Related
I have an existing web app ( asp.net core mvc ) which uses sessions variables to store few lists to persist data which we are looking to clean up.
Thinking of using IndexedDb (localstorage client side ) or Redis ( for a server side approach with session outproc ) . Would appreciate and looking forward to have few thoughts shared to decide which would be better in case there needs to be few lists of medium sizes (say 10000 records ) which needs to be persisted across few requests.
TIA
I think in your case it will be better to use Redis rather than using the IndexDDb.The primary reason for that is the browser support for Indexdb is not consistent across all the browsers and also that will bring minimal changes in your application.The ideal solution will be totally to get rid of session variables. There are multiple ways you can achieve that
1) if there is small amount of data that needs to be persisted you can persist that in cookies rather than session variables.
2)Using the tempdata if the data needs to be shared across just multiple
requests but if the data needs to be shared throughout all the requests then in that case it will not make any difference.
In general the stateless applications are always helpful as then you have the flexibility to scale them without need to worry about how the state is maintained.
I'm currently designing a new website built on MVC and I wonder what is the right way to manage state.
The state should contain the userId and some structs of the user info, and should be kept during the whole session of the user while he's logged in (across http requests)
The important criteria:
1) Support scalability
2) Performance
The easy way is to use the Session object, but it doesn't support scalability. If different requests during the session go through different IIS servers, the session won't be kept. Although I've heard of load balancing tools which route all requests of a single session through the same machine, I'm not sure that it's a good practice to rely on it (isn't it?)
Another option that I've read about, is keeping the state data in special state servers which are running a RAM DB (like Cassandra for Linux or Redis for Windows). But it seems to me an overkill at this stage of the development.
Do you have any other suggestions?
I would like to start with something simple at the moment, but keep the design ready for a more advanced solution at the future.
Any best practice or code/design suggestions will be appreciated.
Thanks,
Edi.
(1) Use Sql Server to Store Session State
(2) Use Memcached as a Session State Provider
(3) Cook up your own solution using Caching on an external caching provider: look into using something like the ServiceStack Caching Framework. Using this, you can use Redis, Memcached, Azure or AWS to handle caching.
Next, create a KeyFactory to handle generation of keys for specific items. The item keys would include the UserId (which you would always have from FormsAuthentication UserId (assuming that you are using FormsAuthentication). Then store any Session data for the user in the cache. Using this approach you are using Caching in place of Session, and the cache can be shared across multiple servers.
Note: you can have different approaches regarding clearing out the user's data whenever they begin a new session. Potential approaches include:
Include the user's session start dateTime in the cacheKey, and auto-expire entries when they are no longer fresh
Clear out all potential entries for a user when they begin a new session
If you are using .NET 4.5 and dependent on the type and amount of information you are keeping on users you may want to look at using claims to store information about the user. In .NET 4.5 all Principals inherit from ClaimsPrincipal. ClaimsPrincipal already uses claims to store the user name, roles and other information. You can create your own service to transform claims, which will allow you to add additional information to the Principal user.
I would like to be able to share some data between an asp.net mvc application and a python/django application . The type of data I would like to share are authentification or session data.
This is of course possible as long as you access some shared resources between both frameworks. There are likely several ways of doing it but one of the most obvious would be using some shared backing store ie. database or maybe even memcached which would be faster. I'm not a Django user but as far as I know memcached is supported in it...
There is of course a more complex scenario related to this and that is data compatibility. You will likely have to use some interchangable format that both frameworks understand ie. XML, JSON, BSON or similar. So even when using memcached you will have to do this translation.
How I would share session...
Make the Session Cookie sub-domain agnostic
<httpCookies domain=".mydomain.tld" />
Have my two sub-domains that I want to share session between
www.mydomain.tld [ASP.net MVC app]
extra.mydomain.tld [Python app]
Create a simple web service or generic handler in ASP.net that returns the user's session serialized in JSON or XML.
If you use generic handler remember to use the IReadOnlySessionState or IRequiresSessionState interfaces on the class.
Now from extra.mydomain.tld you can call your www.mydomain.tld/[Get/Set]SessionValue handler or service. It will pick up on your ".mydomain.tld" cookie and allow sharing modifying values.
I would recommend the following approach using a shared database (could be a shared cache or any other datastore):
When a user accesses one of your applications at your domain, you create a cookie with the key "_shared_session" and with the value of a random string generated by your application;
Save the value of this cookie into the database and relate it to a JSON object holding the data you want to share between applications;
When the user accesses the other application, you verify if the cookie with the key "_shared_session" exists and read its value;
With the value of the cookie, you can retrieve the shared JSON object.
Quick answer: there should be a filter that look for a shared cookie before creating a new session
There is an option for storing Session state in MS SQL Server database which is available out of the box. Use the steps from the next kb http://support.microsoft.com/kb/317604
It's more about configuration, not implementation.
You can write your own custom storage provider but is there any reason for that?
I'm not familiar with python, but there are at least ODBC drivers for it
http://wiki.python.org/moin/SQL%20Server
I notice in the azure examples they are using:
<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
Can someone explain what this is used for with MVC3? I'm very confused about session state. Do I really need to use it if my application does not have anything like a shopping cart? Is it needed if I just want to do simple authentication? I removed the code from my web.config and my authentication still seems to work.
If you're publishing your application to Azure and you're using Session in any way (this includes MVC's TempData) then you will probably need to use some kind of central storage for session, rather than using the default "InProc" provider which just stores the user's session in the application's own memory. With azure, you can use, among others, SQL Azure or the AppFabric Cache (still in CTP).
Here is a good lab for AppFabric:
http://msdn.microsoft.com/en-us/gg457897
And here's one for SQL Azure (not supported): http://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx
This is because you could have mutiple instances running or you instance could be moved at any given moment.
It sounds like your application doesn't currently use Session State so you won't need to worry about it. (although, remember that the TempData dictionary uses Session under the hood)
Our current project at work is a new MVC web site that will use a WCF service primarily to access a 3rd party billing system via a web service as well as a small SQL database for user personalization. The WCF service uses nHibernate for the SQL database.
We'd like to implement some sort of web farm for load balancing as well as failover and maintenance. I'm trying to decide the best way to handle nHibernate's caching and database concurrency if there are multiple WCF services running.
Some scenarios I've been thinking about...
1) Multiple IIS servers, one WCF server. With this setup, the WCF server would be a single point of failure, but there would be no issues with nHibernate caching or database concurrency.
2) Multiple IIS servers, each with it's own WCF service. This removes a single point of failure, but now nHibernate on one machine would not know about database changes done by another machine.
Some solutions to number 2 would be to use an IStatelessSession so we're not doing any caching and nHibernate is always fetching directly from the database. This might be the most feasible as our personalization database has very few objects in it. I'm also considering a 2nd-level cache such as memcached or Velocity, but it may be overkill for this system.
I'm putting this out there to see if anyone has experience doing this sort of architecture and to get some ideas for a solution. Thanks!
am i missing something here, i don't see a problem with nhibernate on the webservers.
application cache would not be a problem as each nhibernate box would keep it's own cache which would be populate from the datastore. look at creating a table that can be monitored for reasons to do a cache refresh. we used to do this using using CacheDependency class in .net 2.0 that would detect changes to a column and then remove the relevant item from the cache. so if a user inserts a new product, the cache would be dropped and the next call to get the products would load the cache again. it's old but check out: http://msdn.microsoft.com/en-us/magazine/cc163955.aspx#S2 for the concept. cheers
I would suggest not doing caching until not doing caching becomes a problem. Your DB will do its own caching to save you searching for the same data repeatedly, so the only thing you have to worry about is data across the wire. Judging by your description, you're not going to have a problem there. If you ever get to a stage where you do, use a distributed cache - allowing your servers to cache separately will cause you bouncing data problems on refresh.