Has anyone some feedback on DataCacheSessionStoreProvider included in AppFabric ?
(Performance, Best Practices, Design guidelines, ...)
Thanks
Good out of box solution if you want to use AppFabric as your caching system. In our performance tests AppFabric session cache performance is about 2000 requests per second (AppFabric 1.0? only one server without secondary caches). It seems that this WCF service performance limit.
Though i have never use it with AppFabric but I've used NCache session Store Provider.NCache lets you transform your regular ASP.NET sessions into distributed sessions without any code change. You follow a few simple steps and your existing ASP.NET applications can immediately benefit from powerful distributed sessions. please check This Link, it might help you .
Related
I know that AppFabric gives possibility to efficiently track and store workflows.
Anyway, for pure persistence, there is also the SqlWorkflowInstanceStore (which, I guess, is used by AppFabric).
I would like to understand which are the advantages of using AppFabric instead of simple SqlWorkflowInstanceStore and which is the overhead of this choice.
Thanks,
Francesco
If all you are interested in is persistence go with the SqlWorkflowInstanceStore. Windows Server Appfabric adds management and tracking capabilities to that. But Appfabric is a plugin for IIS so only works for workflow services.
Appfabric includes several services which enable the restarting of workflows (if your using xamlx via WorkflowServiceHost). You need to perform most of the management techniques of not only starting but restarting a workflow was was terminated in mid stream by something like a server dying.
I found that appfabric really required me to explicily host my workflows using WorkflowServiceHost to be able to correctly use automated management methods that appfabirc exceled at
MSDN - AppFabric Persistence
If you arent using XAMLX (or WorkflowServiceHost) and instead using the WorkflowApplication to host your workflows then I couldn't find a good way to truly utiliize appfabnric and then that mean just using the WorkflowInstanceStore instead
MSDN - WorkflowInstanceStore
I'm wondering if there exist any distributed ASP.Net State Service alternative.
Session can be stored in InProc, StateService or SQL. You can also write custom storage providers. For load balancing (without any form of sticky IP) only SQL/Custom will work.
Are there any alternative ASP.Net State Services that is distributed? I'm thinking so each server can synchronize with the others.
Edit: In response to answers: I am looking for Session() storage. Distributed cache is not a problem, Velocity will do fine for distributed caching. :)
Edit2: In response to Oded: State server has the problem of single point of failure. SQL server may not be directly accessible because of the model chosen (i.e. 3-layer), it is only accessible through the middle layer.
I thought thats what "velocity" was going to be bringing to the table? You might want to check out Microsoft AppFabric for your needs.
Edit:
Maybe I'm missing something about your post and your edit, but I'm still pretty sure AppFabric is what you need for your Session() storage. Maybe I'm wrong, but it sure seems dead on to me.
I would look at Memcache for .net
Take a look at this:
http://technet.microsoft.com/en-us/library/cc725582(WS.10).aspx
I'd recommend to stay with SQL server since it will be the easiest to implement.
Make sure the classes you store in session are marked as [Serializable] or you will get runtime errors.
A little background: I currently make use of Memcached Providers for managing session state in my ASP.NET application. It provides facilities for using SQL Server as a fallback storage mechanism (when sessions need to be purged from the memcached cache). I'd like to look at creating a provider for RavenDB as it would be much more performant for this sort of task.
My question is, has anyone implemented such a thing? (or something similar?) - I'd hate to re-invent the wheel. Google does not yield any helpful results (other than my question about this in the RavenDB group itself), so I thought I'd take this question directly to the Stack Overflow community.
I was also seeking a RavenDB session-state store, and my search also failed.
So I created one:
github.com/mjrichardson/RavenDbSessionStateStoreProvider
Also available via a NuGet package.
Not as far as I know. RavenDB is pretty active project and Memcached has been practically dead for 2 yr and remained 32-bit. You might be better off just running RavenDB under IIS
OK, so code-wise it doesn't get smaller than this - single file: http://sourceforge.net/projects/aspnetsessmysql/files/MySqlSessionStateStore.cs/download
RavenDb provides a Session expiration bundle which means that documents are deleted after a specified lifetime. This is ideal for use as a session and means that your entire aggregate root will be retrieved from RavenDb, meaning much cleaner code:
RavenDb Expiration Bundle
First of all to give you a bit of background on the current environment. We have a number of ASP.NET applications, all of which use session for certain aspects. We are "Load Balanced" over multiple servers due to traffic levels, however, our load balancing is set to use "Sticky Sessions" as currently all web applications are set to use "InProc" for session state.
We are looking at being able to remove the "Sticky Sessions" configuration on our load balancer, as due to our traffic loads servers can and do get overloaded. We want to go with a more balanced approach, but must be able to use session.
I know that SqlServer for session state will work, but for reasons beyond our control, we cannot use SqlServer to store our state. In researching it seems that StateServer is our best bet. We have an additional server, with loads of memory sitting around. This server could be our StateServer for the entire Web Cluster. We just want to know the following things.
1.) Besides any potential serialization issues with the switch from InProc to StateServer, are there any major known issues with losing session objects or generating errors with the above listed environment?
2.) Aside from the single point of failure, and slighly slower performance are there any other gotchas that we need to be aware of with using StateServer.
3.) Are there any metrics that show the performance differences between the three types of state storage?
Here is a decent FAQ on asp.net state: http://www.eggheadcafe.com/articles/20021016.asp
From that Article, here is some information on StateServer:
In a web farm, make sure you have the same MachineKey in all your web servers. See KB 313091 on how to do it.
Also, make sure your objects are serializable. See KB 312112 for details.
For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details
I have only used sql and in-proc. But these 3 that apply when using sql server apply as well:
Avoid storing too much information in the session, as it affects both in serialization and data transmitted over the network.
Make sure you don't have anything that depends on the Session_onEnd. This is just not available for out of process sessions.
Turn off session on pages that doesn't uses it. This don't make a difference for in-process session, but for out of process it will save you a lot.
Make sure your server etag ids are synchronized across the web farm otherwise caching at client browsers will be upset.
Have you reviewed your code in detail to make sure everything can be serialized out of process and across a LAN efficiently?
Are you solving the main performance problem within your system? I ask because the database is the typical source of contention.
My main motivation for moving away from sticky sessions was operational flexibility i.e. cycle down a problematic server or to deploy a software upgrade. So having implemented a central session state service make sure you take full advantage from an operational stand point.
In my experience we've found out that native state server or even using SQL Server for sessions is a very scary scenario as both have issues (mainly performance). By the way, we are also using sticky sessions.
I think you can explore other products for this to achive the absolute best. A free option would be Velocity but it is still not released.
And another comprehensive but proven product will be (Very expensive actually) NCache. THis will even help in your serilizations with less cost, If you use their API's it will be even better results.
Take a look and see which looks best for you.
About SQL Server, you server will die very soon if you have enough number of hits coming in (I belive you have some hits already which yielded you to do Web Farm or you do it just for the sake of redundancy)
Bottom line: We are evaluating Velocity because NCAchce is really expensive. However advantages are huge.
We are using StateServer for a very small web farm with only two nodes for a few hundred users.
I'm not responsible for its operation but I remember only two issues in two years where the service had to be restarted because it crashed.
I would like to another one more point to the accepted answer:
Make sure the version of framework dlls is the same.
In my case the System.Web dll versions were different as a few windows updates were skipped on one of the servers of the farm.
When starting a new ASP.NET application, with the knowledge that at some point in the future it must scale, what are the most important design decisions that will allow future scalability without wholsesale refactoring?
My Top three decisions are
Disabling or storing session state
in a database.
Storing as little as possible in session state.
Good N-Tier Architecture. Separating business logic and using Webservices instead of directly accessing DLL's ensures that you can scale out both the business layer as well as the presentation layer. Your database will likely be able to handle anything you throw at it although you can probably cluster that too if needed.
You could also look at partitioning data in the database too.
I have to admit though I do this regardless of whether the site has to scale or not.
These are our internal ASP.Net Do's and Don't Do's for massively visited web applications:
General Guidelines
Don't use Sessions - SessionState=Off
Disable ViewState completely - EnableViewState=False
Don't use any of the complext ASP.Net UI controls, stick to basic (DataGrid vs. Simple repeater)
Use fastest and shortest data access
mechanisms (stick to sqlreaders on
the front site)
Application Architecture
Create a caching manager with an abstraction layer. This will allow you to replace the simple System.Web.Cache with a more complex distributed caching solution in the future when you start scaling you application.
Create a dedicated I/O manager with an abstraction layer to support future growth (S3 anyone?)
Build timing tracing into your main pipelines which you can switch on and off, this will allow you to detect bottle necks when such occur.
Employ a background processing mechanism and move whatever is not required to render the current page for it to chew on.
Better yet - consider firing events from your application to other applications so they can do that async work.
Prepare for database scalability, place your own layer so that you can later decide if you want to partition you database or alternatively work with several read servers in a master-slave scenario.
Above all, learn from others successes and failures and stay positive.
Ensure you have a solid caching policy for transient / static data. Database calls are expensive especially with separate physical servers so be aggressive with your caching.
There are so many considerations, that one could write a book on the subject. In fact, there is a great book and it is free. ;-)
Microsoft has released Improving .NET Application Performance and Scalability as a PDF eBook.
It is worth reading cover to cover, if you don't mind the droll writing style. Not only does it identify key performance scenarios, but also establishing benchmarks, measuring performance, and how to apply what you learn.