I have basic understanding of session state modes,i have gone through this article on MSDN but not able to understand When to use InProc,StateServer and SqlServer session modes?more specifically confused between when to use State server and when to use sqlserver?
The 3 various modes help spread out your state in different ways to make your application more scalable across a farm and to make it more robust in its own operation.
InProc
InProc is the most basic session management scenario where the the session is stored attached to the process that is actually running it. This means it has the fastest response time because the server doesn't have to go to an alternate source to fetch the data it needs. While it's technically the fastest, it's also the weakest because it can only be used on the server which is running the website. It also is prone to memory dumps. If your site crashes for any reason, the sessions are dumped along with the process. For small, very stable sites, InProc is perfectly acceptable and possibly even ideal. InProc also has the benefit of being able to hold any memory object in session. This can also be problematic if you attempt to hold enormous objects.
StateServer
StateServer refers to the ASP.Net state server service that can reside on any particular machine. It typically operates on port 42424, and can service a single machine or many machines. It is intended to be faster than the SQL server state management methods, but I would argue that the difference in speed is negligible. Perhaps in very large enterprise environments the difference becomes noticeable, but for the web farms I've seen it is not. StateServer requires that any objects in session be Serializable in order to be stored and transferred properly. This means that not just any object can be placed in session, so you have plan ahead when constructing your classes. The state server can be on the machine your website is on or it can be on a machine that is accessible through the 42424 port. This means that session data is decoupled from the IIS process and is therefore "immune" to crashes and hangs. This allows you to have a farm of servers using a common state server, and load balancing becomes simple if the client does not need to be restricted to a specific server. While the state server service is fairly rapid, it operates on a port that many network administrators consider to be simply another "attack vector" for intrusions. Which leads to the SQL state server.
SqlServer
SqlServer mode operates much the same as StateServer. Objects must be serialized, the sql server can be local or it can be remote making it less prone to single server crashes in a farm. Network administrators tend to prefer sql servers for state management because they reduce intrusion vectors. Since your website will likely need a sql server to perform data access anyway, this is just piggy backing. Sql server also allows you to visibly inspect what is in the state tables.
My preference typically is for the StateServer. It is very easy to get up and running and you can have a common one that holds state for many environments that are not related (re: dev, qa, etc). It requires no actual maintenance and is very easy to set up. It also does not require licenses to run as sql server does. However, as your need to decentralization and security increases, sql server becomes a much more friendly option. Use InProc for only the most basic sites or sites with limited traffic.
Related
I've read about various cross-machine caching mechanisms (Redis, Velocity, nMemCached, etc...). They all seem to require a central machine to manage the cache.
Is there such a thing as a cache engine that self installs - e.g. if caching does not exist on the current subnet, it creates a node. If it does exist, it joins the machine to the caching pool?
Context: I have an app that deploys to around 100 users within the same subnet via ClickOnce. Each of these users access a resource via the WAN (across country and in some cases across the ocean) that performs very CPU-intensive computations and takes significant time to complete.
As a result, the app feels sluggish. I've done what I could to alleviate that by throwing long-lived queries onto separate threads. But that only takes you so far. I've added local caching (via a SQL Compact DB) which works pretty good, but most users access the similar information and together they exert a bit of pressure on the computation server. I think I can take it to the next level if I am able to ship an in-memory cache with my app that is able to seemlessly work with other machines to create a network wide caching mechanism.
You're the one who knows what will be the best, but having a "server app" that would coordinate the whole lot might be a good thing :
User1 asks Server "I need X".
Server tells User1 "Well, ask for it to DataBase"
User2 asks Server "I need X."
Server tells User2 "User1 got it."
...
User1 tells Server "I don't want X anymore."
You could also make some type of data "uncacheable" due to their volatile nature, or to avoid clogging one of the users' connection. Sure the server will get a lot of requests, but if you'd have to compare this with a broadcast across the network solution. If I didn't understand your problematic correctly, just write a comment, disregard this, and I'll remove the answer not to mislead SO Users.
If you don't want a master machine, or you don't want to rely on a specific network layout/installation, you could consider Peer to Peer as an option. WCF has native peer to peer support. Here is a link that looks somewhat relevant to your need: How To Design State Sharing In A Peer Network
I have been tasked to scale out the session for an application. From my research the most obvious choice is to use the State Server session provider, because I don't need the users sessions to persist (SQL Server Session provider)
About the app:
Currently using InProc session provider
All objects stored in session are serializable
All objects are small (mostly simple objects (int, string) and a few simple class instances)
Before I dive head-first into the IT side of things and with the ability to provide a custom session provider with ASP.NET 4, should I even consider a custom session state provider. Why or why not? Are there any "good" ones out there?
Thanks!
User feedback:
Why are we using session: persistence of data between postbacks (e.g. user selections)
How: user makes a selection, selection is stored. User leaves a page and returns,
selections are restored. etc. etc.
Will be creating a web farm
I've provided some links you can read up on on properly scaling session using the state server.
Useful links from Maarten Balliauw's blog:
http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-%28aspnet_state%29.aspx
http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning.aspx
http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning-using-State-Server-Load-Balancing.aspx
My State Server related projects:
http://www.codeproject.com/KB/aspnet/p2pstateserver.aspx (latest code at https://github.com/tenor/p2pStateServer)
http://www.codeproject.com/KB/aspnet/stateserverfailover.aspx
Hope that helps.
It depends on what you mean by "scaling" session storage. If your simply talking about session state performance, your not going to beat the in-process session state provider. Switching to the State Server provider will actually make things slower -- due to the extra overhead of serializing and transferring objects across process boundaries.
Where the State Server can help you scale, is that it allows multiple machines in a load balanced web-farm to share a single session state. It is limited by machine memory, however, and if you will have lots of concurrent sessions you may want to use the SQL Session State provider.
For the most performance in a web farm, you can also try using AppFabric as was previously suggested. I haven't done it myself but it is explained here.
Also, here's a link for using Memcached as a Session State provider. Again, I haven't used it, so I can't offer an opinion on it...
EDIT: As #HOCA mentions in the comments, there are 3rd party solutions if cost isn't an issue. One I've heard of (but not used) is ScaleOut SessionServer.
I would highly recommend that before you look in to scaling out session that you first evaluate whether session was even needed in the first place.
Session variables are serialized and deserialized for every single page load whether the page uses that data or not. (EDIT: Craig pointed out that you have some level of control over this in .net 4 http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatebehavior.aspx However, this still has drawbacks, see comments to this answer.)
For single server instances this is okay as you are just pulling it from the local memory of your web server. The load on these apps tend to be pretty small so caching user specific information locally makes sense.
However, as soon as you move storage of session to another server you have increased the network requirements and page load times of your application. Namely, every page will result in the session data to be moved from the remote server, across the network wire, and into memory of the web server.
At this point you have to ask yourself: is the load to pull this information from the database server directly as necessary more than pulling it from the session server every single time?
There are few instances where pulling it from the database server as needed takes longer or results in more traffic than grabbing it from a remote session server.
Bearing in mind that a lot of people set up their database server(s) to also be session servers and you start to see why use of session doesn't make any sense.
The only time I would consider using session for load balanced web apps is if the time to acquire the data exceeded a "reasonable" amount of time. For example, if you have a really complex query to return a single value and this query would have to be run for lots of pages. But even then there are better ways that reduce the complexity of dealing with remote session data.
I would advise against the use of session state, regardless of the provider.
Especially with your "very small objects" use viewstate. Why?
Scales best of all. NOTHING to remember on the server.
NO worries about session timeout.
No worries about webfarms.
No worries about wasted resources for sessions that will never come back.
Especially in ASP.NET 4 viewstate can be very manageable and small.
I'm going to develop a POS system for medium scale company
and the requirement for me is to make all data on time for all of their branches
while in my mind, move the server from local to web would solve this problem
but, i never done any online server for window application
may i know what is the best option for use as secure database ?
such as SQL can handle this well ?
i tried to google but all of the result return is not what i want
may i know what will you do when you facing this problem ?
my knowledge on coding is just VB and CS
also SQL for database
i would like to learn new if there is better option
i hope it is impossible to access by anonymous and it is store secure at back-end only
What you probably want to do is create a series of services exposed on the internet and accessed by your application. All database access would be mediated by these services. For security you would probably want to build them in WCF and expose them through IIS. Then your Windows application would just call these services for most of its processing.
If you design it properly you could also have it work with a local database as well so that it could work in a disconnected manner if, for example, your servers go down.
Typically you don't move the server off of the site premises.
The problem is that they will go completely down in the event your remote server is inaccessible. Things that can cause this are internet service interruption (pretty common), remote server overloaded (common enough), basically anything that can stop the traffic between the store location and your remove server will bring them to their knees. The first time this happens they'll scream. The second time and they'll want your head due to the lost sales.
Instead, leave a sql server at each location. Set up a master sql server somewhere. Then set up a VPN connection between the stores and this central office. Finally, have the store sql boxes do merge replication with the central office. Incidentally, don't use the built in replication, but an off the shelf product which specializes in replicating sql server. The built in one can be difficult to learn.
In the event their internet connection goes dark the individual stores will still be able to function. It will also remain performant as all of the desktop app traffic is purely to the local sql box.
Solving replication errors is much easier than dealing with a flaky ISP.
I would recommend you to check Viravis Platform out.
It is an application platform that also can be used just as an online database for any .NET client with the provided SDK. It has its own generic windows and web clients and some custom web solutions for some specific applications.
You may be using it as a complete solution or as a secure online database backend.
Starting to develop to actual code to my website and wanted to know how do i develop or design the website that is load balance friendly. I read a post on stackoverflow regarding scalability and the selected answer stated: "Make sure you consider load balancing when developing your application". How do I go about this?
Your decision will come down to environment. If this is a product for sale, you will not have any control over the load balancing implementation. This means that "sticky sessions," where a user is bound to the same server for the duration of a session, cannot be guaranteed. Sticky sessions allow just about any application to be load-balanced, but they are not as efficient.
If you cannot guarantee an implementation with sticky sessions, avoid the usage of Session state altogether, or look into a shared-session solution.
1) do not use static fields to store data, statistics, ...
2) use session with care - you can still use in-process with sticky ssessions but I do not like it.
3) Do not rely on the IP of the server
Well, one answer is to reduce reliance upon session variables. It's possible to share session variables between servers via session server, but that means all your servers have a single point of failure on the session server then, plus reducing performance.
Basically, just try to make each page as stand-alone and stateless as possible, and you'll be good.
This might be obvious to most of you, but actually was an issue in our environment when we started to use a load balancer / several web servers: Do not rely on the IP addresses of your web server.
We had a production environment that used a switch and a set of internal IP addresses, including the one of the web server (our products usually run in a closed off environment, not the open Internet). If you have several web servers that becomes a problem.
Make sure you have a development/QA environment where you can test your software in a load balanced environment and see the issues in your code as you develop it rather than waiting until the deployment day.
One thing to take into account is the usage of Session data to maintain state.
As your application subsequent requests can be handled by other servers in the balance line you can not use InProc mode and StateServer mode.
I am watching the ASP.NET learn videos on asp.net/learn. In this tutorial, they are building a quiz engine. At one point, the narrator explains that we are going to use the Session object to maintain the state between each page (each page contains a question and four answers). He says that "since this is a low traffic website" it is okay to use Session and that he doesn't have the time to implement a more sophisticated method.
I am just wondering what alternate method(s) is he hinting at? And why is session a bad choice for a high traffic website?
Storing data in a database, or in cookies or some other method that is not directly tying up web server memory.
In addition to load, session also raises issues with the ability to use farms since you would either need to synchronize the session across the farm, or make sessions sticky, which can impact scalability.
For alternatives you can read the article Nine Options for Managing Persistent User State in Your ASP.NET Application.
In the articles the author explains the pros and cons of each method.
From the summary:
ASP.NET provides many different ways
to persist data between user requests.
You can use the Application object,
cookies, hidden fields, the Session or
Cache objects, and lots of other
methods. Deciding when to use each of
these can sometimes be difficult. This
article will introduce the
aforementioned techniques and present
some guidelines on when to use them.
Although many of these techniques
existed in classic ASP, best practices
for when to use them have changed with
the introduction of the .NET
Framework. To persist data in ASP.NET,
you'll have to adjust what you learned
previously about handling state in
ASP.
Session data is stored in the RAM of the server, if you have a high traffic site that is going to get full real quick and the last thing you want is that data being swapped to disk.
As gaijin42 says, cookies or a DB are the alternative.
Session as a state storage method is rough in high traffic systems for several reasons.
First, the default Session storage method is in-process, meaning that if you have a load-balanced web farm, you'll constantly 'lose' Session information as a user gets pages served from different servers.
The in-proc Session server also dies when an app pool is recycled, which happens more often on higher traffic servers.
The scalability options for Session data are
Use the freely available ASP.NET
Session Server and point all your
applications at it
Use SQL Server to store Session data.
Due to the nature of Session data in general, neither of these is a very good option for a very high traffic site (unless you have unlimited money to throw at the hardware).
For high traffic websites you might be looking at Memcached. It is a caching mecanism that is stored on the RAM of a remote computer. Just recently a win32 port has been made of the library (was only possible with linux before).
I'm not going to repeat what was already mentioned here, but another alternative is using the Application hash. It should be used sparingly, since it will consume memory on your web server as Adam has already mentioned, but it does provide a good way to cache things that are common across ALL your users.
This keeps you from having to go back to your database to retrieve information that most likely was already asked for by someone else.
Another alternative similar to Application is Cache which has more flexibility in terms of when it gets released, duration, etc.
Here's some links in case you're interested:
ASP NET Caching Application State
We use a database for anything high traffic or that will result in large session state. Instead we store a pointer in the real sessionstate that points to our database record. Then the only overhead we have is the bandwidth between the web server and database server which will be much less than between any given user and the web server.