AppFabric has reached end of life and if you’re thinking about where to go from here then you must watch this webinar. This webinar shows you different ways to migrate your .NET applications from AppFabric to NCache.
NCache is an extremely fast and scalable .NET/.NET Core distributed caching system and it provides a wrapper for AppFabric that allows you to migrate to NCache with minimal to no code changes in your applications. Your Appfabric APIs used in your applications start to work with NCache seamlessly. You can additionally start using many other APIs and features offered by NCache for advanced caching functionality which are missing in AppFabric.
Here is what this webinar covers:
Today’s topic is going to be: “How you can use NCache as an AppFabric alternative?” Today's webinar is going to cover a myriad of topics. Particularly an overview of AppFabric and its end of life issues. As well as, to why NCache is your best alternative to AppFabric and any advanced distributed caching features that we offer, which you can use in place of what AppFabric used to offer and an hands-on example and demonstration, of how you can migrate from AppFabric to NCache?
Now, please note that this is a live webinar, so, at any time you can use the questions tab to insert any questions or queries or concerns you may have and we'll be able to address you. And, finally at the end of the webinar we will also have a separate Q&A session, so, if anyone has any questions that they want to save to the end, we can get to you on those as well. All right, without further ado, Ron you have the floor.
So, today's topic is a very specific one. You know, it's going to cover AppFabric end of life issues and since Microsoft itself has recommended that you should migrate off of this technology. So, if you're using an AppFabric application, if it's still part of your application architecture, we would present some options with NCache to migrate off of that and, you know, I’ll show you how smooth that transition can be. How easy it is to migrate off of AppFabric and be able to use NCache as is and then be able to use some extended features of NCache which AppFabric completely lacks. So, AppFabric is a very limited product. It used to work very well but it's end of life, right, so, it's not being backed up. It's not being updated anymore. So, it's high time that you migrate off of it.
So, today we'll cover all the details. What are different options in regards to using NCache, as an alternative product for App Fabric and how easy it is to migrate off of it and, what are the benefits that you're going to get, if you start using NCache. So, we have some tech details to cover.
So, let's talk about AppFabric in general. I'm pretty sure most of you already know AppFabric and its architecture. If it's being used in your environment, so, you should have hands-on experience with AppFabric. It's an In-Memory .NET Distributed Caching system. It’s primarily used as a free Distributed Cache, which comes as part of Windows Server. It’s mostly used for Web Applications, Middle- tier-services and any other .NET Applications, that need caching to save trips to the database. It was released and supported by Microsoft. In 2010 1.0 was released and 1.1 was released in 2015 and that was the last version of AppFabric. The caching API, how you can use AppFabric? It's primarily going to be .NET Application, consuming AppFabric Data Class and then exposing the Wrapper, you know, exposing the APIs of AppFabric through that library. You can also use some providers, which AppFabric used to have. ASP.NET Session State Provider and ASP.NET Output Caching Provider. So, these were no code change options, which you could use, if you don't want to use data caching, if you're more focused on web specific caching, these were two features, which are available without any code changes.
Here’s the architectural breakdown. It's very simple, that you have your cache servers, which are termed as Cache Hosts in regards to AppFabric. It allows you to formulate a Cache cluster. With some limitations, there was a concept of majority rule. You need to have at least 3 Servers and if any one Server goes down, you violate the majority rule. So, high availability and data reliability can be compromised and then there was a concept of Lead Host as well.
But, idea here is that you have Cache Servers, which are hosting your Cache. They formulate a repository for caching and then your application is able to connect this cache repository, backed up by multiple Servers and allows you to perform caching operations.
It used to have PowerShell based cache administration tools. Cache configuration and Cluster configuration was usually on a storage location, a File System or a Database. So, that was another dependency within AppFabric. So, there's an overview of how, you know, Cache Enabled Application Servers or Cache Clients can connect to this Cache Server, you know, who is going to actually host the Cache in your environment.
AppFabric is end of life, already. The first announcement came in April of 2016. Where, Microsoft started recommending that you should migrate off of this technology because it's not going to be supported anymore. They announced end of life support life cycle for that product, for this product in April 2016 and then they ended main stream support within one year. So 2017 was the end of their mainstream support, as far as, AppFabrics official support from Microsoft is concerned and then the extended support. They've been extending support for a few years now but the current last date is going to be 2022.
So, basically that's the and we expect that this could be the last extension, that Microsoft has given. So, they're highly recommending that you migrate off of this technology. It's not Open Source. So, it does not have any community to back it up as well. Online resources, as far as, even you know, when I was preparing this webinar getting an AppFabric help documentation out of Microsoft portal is very difficult, as you start using it.
So, it's very difficult to get help resources. Official support is not there anymore. Limited extended support is available. No more bug fixes are going to be provided. No more enhancements are going to be added, to the feature set. If you're using newer platforms, such as, .NET Core, platform compatibility, security updates are not going to be part of this. So, it's essentially end of life. It's an obsolete shelf product and this is why Microsoft recommends that you migrate off of it and use alternatives and that's why we're doing this webinar as well, so that, you have an easy migration option, as part of NCache, as your replacement option.
It's very risky to use App Fabric primarily, because Microsoft, the main vendor has given recommendations, to migrate off of it. Production deployments are at risk, as we speak, because of no support, no bug fixes, no enhancements, no compatibility or security updates. You're leaving. The cost of something going down is very high, because you may be using it in a mission critical application and if that application is using AppFabric and if that goes through an issue or it goes down, you don't know where to go. So, it can impact your business and that can impact the overall user experience as well.
So, we recommend that you perform the migration. Specifically, when you have such easy migration options available which NCache offers. So, we highly recommend that you complete this project on priority and as a matter of fact, in this webinar, towards the end of this webinar, you would be fully equipped to use an existing AppFabric application and I’ll show you step-by-step guide to migrate off of that, you know, migrate AppFabric to NCache. That application can be completely, you know, stop using AppFabric and start using NCache and then I’ll show you, how simple it is. It’s a three step process, which I will cover within this webinar and that should give you a very good idea, how to start using NCache as an alternative. Any questions so far?
So, this was just some introductory detail. Some details about, how AppFabric came into existence? What are the issues and how to actually migrate off of it?
So, NCache is a migration option. It's a very natural choice. NCache is 100% native .NET product, which is in the market for over 15 years now, with a complete market track record, with lots of traction, lots of actual custom deployments using NCache in their applications and we have customers all over the place, in different industries as well.
So, I’ve just listed some of the most common, you know, factors here, that you should consider NCache as a, as an alternative. Primarily, because of .NET and Windows support. Secondly, it has a track record within industry or within the .NET Applications and is fully supported. Official regular and 24x7 supporting options are available from our teams. And, we’ll talk about what are the different features which you can extend. So, you can extend your existing caching use case. We see customers coming to us and they have a use case for AppFabric but when they adopt NCache they want to extend their use case and start using those advanced features, which are only available in NCache and AppFabric completely lacks those features. So, that's another factor that you should consider NCache is a migration option.
NCache deployment, in a typically large enterprise, this is how NCache looks like. You have again a set of Servers, hosting the cache cluster and unlike AppFabric, you don't have to have a majority rule or lead host concept. It's a 100% peer-to-peer architectured Cache cluster. It uses TCP/IP based clustering protocol. You create a Cache cluster on team of Servers and these contribute towards request handling capacity from the Client Applications, which are connected to it. So, these could be your ASP.NET or ASP.NET Core Web Apps. It's on newer stack as well. .NET or .NET Core Web Services or .NET Core Server Applications.
So, in general, any .NET, .NET Core or even Java Applications, can connect to NCache and take advantage of NCache caching. It’s very simple.
You can start off with 2 NCache Servers to formulate a cache cluster and 2 is the minimum to get high availability and data reliability features. Even single Server can work but I would highly recommend that you use at least 2 NCache Servers to take advantage of high availability and data reliability. And, it's very flexible. It allows you to create as many caches as you need to. The size can grow, the memory and then there are a lot of features that you get as part of adoption of NCache.
We cover this section in a very detailed manner in our regular NCache architecture webinar but this is more of an introductory slide here, so, please let me know if there any specific questions in regards to NCache deployment.
NCache can be deployed on separate dedicated servers, where your applications are in separate boxes NCache is on separate boxes or you can have NCache and applications on the same boxes as well. So, Windows Server box hosting NCache can also act as your client box, a web server box. It's just that your application is deployed on the same machine where NCache is also running. So, that is also a possibility or you can have separate tier of Caching Servers and your applications can be on separate boxes. So, we're very flexible.
It's available in Microsoft Azure, as well as, AWS and in any public or private cloud. You just need that .NET Framework as a prereq for NCache and that's all it needs. Like I said, it's very flexible, very easy to use product. In comparison to App Fabric, it would be a natural transition from AppFabric to NCache if you plan to adopt it.
So, next I’m going to talk about migration options and I would show you hands-on examples to achieve this.
So, for data caching, although we discussed that we have .NET API and then we have sessions and output caching features with AppFabric, so, this must be your overall use case with AppFabric. If you have a live application running at the moment, so, chances are that data caching is the most common use case, that you must have used in your applications, while using App Fabric.
So, let's talk about how to migrate an application using AppFabric and you start using NCache as a replacement. So, there are two options. We've designed our wrapper, we've implemented it and without any application code changes. You don't need to change any code. You can start using NCache as a replacement of AppFabric. You just need to use our NuGet and update the name space. So, what we've done is, we've implemented our wrapper around AppFabric API, so, in your application whenever you make AppFabric API calls, behind the scenes that wrapper implementation takes that call and starts calling NCache and it's a very simple easy to go option, where your existing application, which I would show you, how to actually manage. I’m going to run this side by side and all your AppFabric APIs would start working with NCache seamlessly. No code changes are needed. Just a library, name space change, would get the job done.
The second option is making a direct NCache API call. In that, you make code changes and you introduce NCache API calls yourself. You can start replacing AppFabric APIs or you can start extending the existing AppFabric APIs and start using the extended features as well.
You can use these two approaches side by side as well. For example, what you already have with AppFabric, you can use our wrapper to get that base covered and then you can use our extended features. Features which are missing in AppFabric, you can start using that through our native APIs.
So, I’m going to demonstrate these two aspects of NCache with the help of sample application. So, this is our wrapper approach.
Before we actually get started, let me set up the environment and show you how NCache gets configured and how easy it is to set up NCache cluster environment. So, for that, I'm going to log on to our demo environment.
/*Replace*/ using Microsoft.ApplicationServer.Caching; /*with */ using Alachisoft.NCache.Data.Caching;
This is our web management tool. This can be accessed from anywhere in your environment. It could be your Client boxes, Application boxes. It could be your current AppFabric Server boxes. You just need to install NCache on one or two boxes and then once NCache installation is done, you can start the web management process and you can configure a cache cluster.
So, I have NCache installed on two boxes here, which I would use as my cache cluster servers. So, all you need to do is come here on the Clustered Cache. You can, by the way, create a Clustered Cache, a Local Cache, a Clustered Cache. You can access it from the IP address itself.
So, you click on New and then you can name it, let's say, democache. You can name anything. NCache is based on Binary and JSON serialization, so, you can choose either of these formats. I'm going to go with Binary and choose Next.
You know, with NCache we have many caching topologies and I would urge you to review our NCache architecture webinar, which covers all these topologies in great details.
So, Partitioned of Replica topology, if I have to give you a quick overview of this, it's based on partitions which are backed up. So, this is our Partition of Replica topology. Each server has a partition of data where clients are connected. So Server 1 and 2 hosts the active partitions. Item number 1, 2 are on Server 1 and item number 3 and 4 on Server 2 and then we have a backup partition as well where Server 1 has backup on 2 and Server 2 has backup on Server 1.
So, in case any Server goes down the backup gets activated and you don't lose any data. So, each server is backed up on other Servers in the Cache cluster and you can have as many Servers as you need to, in this setup and similarly, we have other topologies, which I recommend that you review through our architectural webinar. So, Partitioned of Replica is what I'm going to choose. Keep everything simple.
Mode of replication between active partition and its backup on the other server can be Synchronized or Asynchronous. I’m going to go with Async because it's faster. Sync is more reliable but Async is pretty fast as well.
And, here I’m going to specify Servers which are going to host my Cache cluster. So, I have two boxes 107 and 108.
Let's see if that Cache, TCP/IP based parameters, for communication between Sever Nodes and Eviction can be turned on. Since, you specified a Cache Size here. On this screen, you also specify a size of the Cache. So, you can also choose Eviction to be carried out if your Cache becomes full. So, in that case Cache can remove some older items and make room for the newer items.
If you're using NCache for Session Caching, as a migration from AppFabric to NCache, AppFabric Sessions store module to NCache Sessions store module, we recommend that you turn off Eviction, because that's your user data and even your sensitive data, even if you're using Object Caching APIs, you can turn on Eviction only if you can afford to lose data, if your Cache becomes full. So, you can always give a bigger Cache Size as well by the way, to in order to, mitigate this problem. Start this Cache on finish. Auto start this Cache on service startup. So, each time Server reboots, it should automatically rejoin the Cache cluster, so, there is no downtime or data loss. A Cluster fully functions, if it has all the members up and running, so, on restarts it should automatically rejoin. You should not do it manually and that's it.
That's how easy it is, to configure our cache cluster. As you can see, we have 107 and 108, democache is fully up and running.
And now I can show you some statistics. These are our Windows performance counters. So, again it's very natural choice, where we have Windows integrated monitoring system through Windows performance monitors.
And, we have our own monitoring tool available as well, which is making use of Windows performance counters, as well as some monitoring parameters, within the NCache application. Such as, a number of client connections, some utilization, some stats within the cache host. So, we have fully connected Cluster, Requests/second, Average Microsecond/cache to show you latency, Additions, Fetches, Updates, Deletes/sec Size of the Cache, CPU graph, Memory graph, total data in the Cache Count, CPU Time spent by NCache, System Memory right here and then also the Client Processes which are connected.
So, it's very elaborate and on top of it, it has client dashboard, report view of Server and Client and then you can add your own dashboards as well. Let's say, if I create a new dashboard, it should be named, let's say, Api Logs, I can just go ahead and Create and then I can drag and drop counters from here.
For example, I can see Cluster ops, I can see Additions per second. So, I can just add counters which I need, specifically to monitor NCache Cluster. So, at the moment there is no client application running, so, I'm going to quickly run one and for that I’m going to just say test-stress democache. So, as soon as, this application runs it takes some time for the first time. The PowerShell window on this box is slightly lagged but as soon as this would run, there you go, it would simulate some dummy activity on my cache, there you go and you can see Requests per second coming in.
If, I bring this here, Average Microsecond per cache operation is little less than 100 Microseconds per operation and we have a pretty mix of Additions per second, Fetches, Updates happening. Cache Size is growing, a few Megabytes. It's only a one Kilobyte object size, on average. CPU is less than 5%, 4% at the moment. Memory is what you add and you can see all set of counters are showing activity here.
We have a Client Processes, being shown here as well and if I show you the Client Dashboard, we're seeing all these reports as well.
So, this was just to give you an idea how easy it is to set up. So, this is one of the test, so, if you already have AppFabric Servers, all you need to do is download NCache software from our website, install it on same servers. Two servers is the minimum requirement that we recommend for high availability and data reliability. You can start with one as well, just for testing but we recommend that you use at least two servers in production and once you've done that, you can then move to your application and start using the same cache cluster.
And, then after installation obviously you need to create a create a cache cluster as well which we've just done and then you can start using your application and, then come to your application and start using NCache as a migration option and which I would show you with the help of a sample application.
So, I have this sample application. As a matter of fact, it's same sample application one, with native AppFabric console UI and the second one which I’ve converted from this NCache AppFabric console UI. So, if I open these two, these are exact same applications but with small changes made, in order to make it compatible with NCache. So, and I’ll walk you through those changes. I have a separate copy of this which I will demonstrate. So, I've set this as a Startup Project, right and I’m planning to run this and by the way before I run this, I have an AppFabric Server up and running here as well. So, we have AppFabric Server. If i just show you the current stats, I have some, you know, let me just restart this and while this is being restarted, let me come back here and this is using a typical AppFabric, you know, data caching calls. Let me see, if I show you from here, Program.cs.
Is there a question? I wanted to throw one your way. Yes. One of our attendees mentioned, back in slide six, that it mentioned that the Cache cluster is running on Windows and Linux, so, can the Server be hosted on Linux and if so, then how does the dashboard feature work.
Very good question. This is a web based management tool, which is implemented in ASP.NET Core, right and it has all the tools available for Linux environment as well. So, if your NCache Server is hosted on Linux. First of all, you can still access the web management, which would be as part of Linux. You can access it from any Windows box or from any browser within your environment and for Linux monitoring, we don't have PerfMon counters in Linux yet, right.
The .NET Core is still being evolved so, PerfMon counters are not there as yet. So, we've given our custom counters for Linux environment. You would get almost similar view of Linux server monitoring out of NCache. So, the only difference would be that it would be Linux box instead of Windows and you can have a .NET Core installation on those Linux boxes.
So, the view would be same. It's just we've chosen a different route, to overcome a limitation of .NET Core. PerfMon counters are not there, so, we've implemented our custom monitoring for that particular use case. I hope that answers your question.
So, let me just clear this and show you the current stat. So, this is a ‘democache’, same name, you can even use the same named cache with NCache as well. You don't even have to change the name of the cache. That's how we've designed this. Right, so, let me just show you statistics of this cache. So, nothing at the moment is in the AppFabric cache cluster. So, I'm going to start this application.
So, my goal here is that we run an application with AppFabric, show you that it works and then we migrate off of this, migrate this off to NCache and stop using AppFabric and start using NCache. So, I'm going to run this.
All right. So, this is my personal test case, sample application, that I've designed it. It's going through all the APIs, possibly all the APIs of AppFabric. That's why you're seeing a lot of APIs being executed at this point. So, I'll just run this with AppFabric and then run the same sample which would have and it would have notification test as well by the way. So, while this is being done, let me just dock it here and then bring this one right here. Actually, let me just open this sample right here. Okay, so, basically same sample application, my bad. All right. So, this is with, you know, AppFabric and let me show you this sample has done some additions, so, if I show you the statistics. We have Item Count to be 48, Region Count 60, Request Count 154.
So, we have a bunch of parameters and if I show you the keys in the cache, you can see, you know, some stats within the cache. So, it has some items. One the primary on the, you know and it's only have one server at the moment but we have regions added in the cache as well.
So, it's a fully working sample application and now I’m going to run the same sample and then I’ll show you how to make, how we've done the changes as well, by the way. So, I'm going to come to this sample, which is a copy of the first one, which we ran with AppFabric and made changes to equip it with NCache. Start new instance and that should run here. So, you can see same sample is being executed with NCache and I’ll show you all the changes in a bit.
So, the side-by-side comparison would really help you, that we've, what we're expecting from sample one from AppFabric and what we're getting from NCache is going to be exactly same and would not making any code changes, in order to achieve this. I'll walk you through all the steps that we've done. So, it's almost completed. So, let me just come to the very top. It's still running by the way. So, you can see the yellow marker is basically, is the task that we're doing and if it's completed it would show you in the green and if you see an error from the server side you would see, you know, the darker red, lighter right and then darker red, if it's on the parsing side, on the client end. So, I’ve just given them a color coded view. So, you can see all the outputs are exactly the same, including the error codes and any exceptions that may have encountered. So, starting from here, adding key value, adding a non-existing key, same output here. So, add item to the test, that's also this same output, get item, item six, you know, success on this one as well, error. So, you can see side by side view and this is exactly matching with NCache, right.
So, towards the end, I would just show you some events. So, it's using regions as well, right. So, region use cases right here and you would see the same output out of NCache as well. So, clearing region, adding region, remove region test, is actually performing exactly the way it is supposed to be. So, that's a quick demonstration that we were able to achieve this.
Let me show you what are the steps, which are involved. Now I’m going to close this down and by the way you have all the monitoring, which I should have shown but let me just show you the steps that we performed. All we've done is, we have a NuGet package added and for that actually let me just go through this step by step. So, what you really need to do is, this is your App Fabric console UI. So, it's using AppFabric at the moment.
So, first thing that you need to do is add a NuGet package. So, if you go to manage NuGet packages, so, you can see some installed NuGet packages or you can browse and see some let's see AppFabric NCache. If, I click on this, install this. So, that's our first step.
So, if I come back right here, within the migration option, with no code change option, first thing that you need to do is introduce our NuGet package which is AppFabric.Wrapper.NCache and then this next step is that you replace Microsoft.ApplicationServer.Caching; namespace with the Alachisoft.NCache.Data.Caching; This is the wrapper assembly and NCache would take charge of all the calls from that point onwards.
/*Replace*/ using Microsoft.ApplicationServer.Caching; /*with */ using Alachisoft.NCache.Data.Caching;
Let me do this in front of you. So, this is the sample, which is native AppFabric sample. We have the NuGet installed. It's still being done.
Quick question I throw your way with this. Question was, getting items by tags are supported by the wrapper?
Yes. Getting, you know, the AppFabric has regions, right. So, if you're using regions within AppFabric, so, we will be using tags and then groups to support that but if you want to use NCache tags, right. So, you want to extend your caching use and that's a topic within the webinar as well, in that case you can use our APIs directly. So, use the wrapper, to support what you already have through regions, tag is being used behind the scenes and then if you want to use tags specifically offered by NCache, NCache API. So, you can use it direct NCache APIs as well. So, I hope that answer your question.
So, I'm going to go through this one by one, right, and simply use this slide right here, so, we need to use Alachisoft.NCache.Data.Caching; right, so, that's the idea here. So, I'm going to go through this, add in the cache. Doesn't have any reference of AppFabric but this one has. So, all you need to do is, include this name space Alachisoft.NCache.Data.Caching; and that's it.
So, NuGet package has added a bunch of resources right here NCache, you know, Data.Caching which is the wrapper and then NCache regular assemblies and all of this is what you need. The NuGet is adding NCache client resources into your application and then you go one by one and then start replacing this.
Let me just come back here and copy this so that wherever you find AppFabric reference, for example, here, replace it with NCache and I’m doing this in front of you so that you see how easy it is. So, we keep on going. I'm sorry my bad, using Alachisoft.NCache.Data.Caching; and let's repeat this. There was a typo, so, I think I got rid of it as well. All right. So, I'm going to move on to other tests. This is fine. Clear region is fine, create region is fine. So, all the region tests are not using any direct references but and then we have tags test. So, I'll post this sample on GitHub as well. By the way, our NuGet is already live, with the latest service pack information but I’ll post this one in the. So, I hope I've completed all. Let me just rebuild this. If there are any errors, I’ll just go and specifically tackle those. So, in this I think. All right. So, let me just validate that I’m using the right wrapper out of it.
All right. So, once you've done this, let me, you know, I think I’ve missed a few but once you've done this, you need to come back here and add your client-side connection settings. For example, in my case, it's this box right here, 101, which is my own box and the config has to have the name of the cache.
For example, we had ‘democache’. So, i'm just going to show you a local testing with my local cache but you can always use remote cache as well. For example, for that I can use this cache right here. Let me add my box as a client, right and then add this, my box has a client node, for example, 101 is a client machine.
All right. So, I have all the settings now. So, I can either use the client.nc conf or i can just point towards 107 as a client box from here.
Right. So, this is one thing and then app config needs to point towards the name of the cache. So, I don't plan on changing anything here. Now let me run this sample with my actual cache. It built fine. After that I would just run it. I'll just make it as a startup project as soon as it completes. Start a project and then let's run it.
So, it's essentially a three-step process. You can include our NuGet, replace your AppFabric library, ApplicationServer.Caching with the Alachisoft. NCache.Data.Caching. Rebuild the application. Make sure there are no errors. Use our latest NuGet package and update client.nc conf to point towards the server that that you've just chosen and in this case, we have a client.nc conf file which gets added by the way from the server. Now that you have a cluster configured. Just point towards that server and if I come back right here we now have, let me just monitor this and let me close the stress test tool down. Right. So, we should have stats being shown from the application itself, right.
So in general, that's the life cycle of how to migrate off and use our wrapper approach.
Let me just show you the direct API call usage as well. Now the second approach where there was a question as well what happens if we use NCache tags or NCache features? So, we have a lot of advanced features available. So, you can make direct NCache API calls on top of your AppFabric application. So, for that, I would recommend that you use our help documentation as a guide and this is our direct API. So, all you need to do is ICache cache = CacheManager.GetCache and get the cache handle and then start using NCache APIs and, for that all you need to do is use our SDK and we have a sample application which gives you ability to add all of this into any general purpose application that you have.
ICache cache = CacheManager.GetCache("myDistributedCache"); cache.Dispose();
Employee employee = cache.Get<Employee>("Employee:1000"); bool isPresent = cache.Contains("Employee:1000");
cache.Add("Employee:1000", employee); cache.AddAsync("Employee:1000", employee); cache.Insert("Employee:1000", employee); cache.InsertAsync("Employee:1000", employee);
Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
So even application using a wrapper approach can extend that usage and you start using NCache APIs at a later stage as well.
So, if I open the samples and for that I will show you NCache samples. Basic Operations is a very simple sample application, which gets the job done. So, this basic operation sample is ready. It has a very simple approach, basic operation, so, all you need to do is add Alachisoft.NCache.Client library.
So, like I said, you can use this as a reference and wherever you have AppFabric, for example, if I open the Bulk Get Tests, you can include this name space here, right, and within that, within this let me just actually take it in the form, where we actually need it. So, please bear with me. Let me find where should I add it, because I don't want to change anything in the sample. Right, I think it's just using AppFabric wrapper test on top of it. So, I think, I should stick to this basic operation sample. Right. So, this is our ICache class cache and then you can use Create New Customer, which is your object and then you can say Add Object To the Cache, which is your implementation, custom implementation but this is how you would use NCache APIs.
You could construct a cache item and then you call Cache.Add and this represents NCache, you know, APIs Alachisoft Cache object. So, it's the Alachisoft.NCache.Client.ICache.
So, it returns a cache handle and allows you to use NCache APIs on top of it. So, like I mentioned that you can start off with migration through wrapper and then you can use our extended APIs on top of it and then there are a lot of, you know, documentation resources available, where you can see how AppFabric APIs look and how NCache APIs. So, if you want to really stop using AppFabric and start using NCache APIs, you can start from the very beginning and then use this approach, or you can use a side-by-side approach, where you use the wrapper for easy migration and then extend on top of it by using NCache APIs.
We already done this. So ASP.NET Session Caching, you just change the provider in such a way that you can provide web config changes to point towards NCache as a session storage and output you can just point towards NCache as an output caching provider. We have detailed help documents available on this front as well. For example, if you say NCache Session Caching, it will point towards our session state provider and similarly you can look for output caching as well. Right, so, this is what you need to modify within the web config.
<configuration> ... <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" cacheName="demoClusteredCache" sessionAppId="demoApp" exceptionsEnabled="true" writeExceptionsToEventLog="false" enableLogs="false" enableSessionLocking="true" sessionLockingRetry="-1" emptySessionWhenLocked="false" /> </providers> </sessionState> ... </configuration>
Same goes for output caching, which is right here. So, if I provide provider overview, this is what you need to add inside your application to raise App Fabric output caching with NCache output caching.
<!-- caching section group --> <caching> <outputCache defaultProvider ="NOutputCacheProvider"> <providers> <add name="NOutputCacheProvider" type= "Alachisoft.NCache.OutputCacheProvider.NOutputCacheProvider, Alachisoft.NCache.OutputCacheProvider, Version=x.x.x.x, Culture=neutral, PublicKeyToken=cff5926ed6a53769" cacheName="demoClusteredCache" exceptionsEnabled="false"enableDetailLogs="false" enableLogs="true" writeExceptionsToEventLog="false"/>" </providers> </outputCache> </caching>
And, on the left side you can see the list with NCache is huge. Multi-site sessions are supported, view state provider is supported, which is missing in AppFabric. Output caching with custom hooks is a unique feature to NCache. Similarly, we have SignalR Backplane, ASP.NET Core Response Caching, ASP.NET Core SignalR Backplane. So, this list is something which is very extensive, because we're actively updating our feature set in comparison to AppFabric.
And, then in general, you know, NCache is 100% peer to peer architectured in comparison to AppFabric. Many caching topologies in comparison, which you can review. WAN Replication is available. Multi Datacenter support is available, out of NCache, where you have Active-Passive, Active-Active or 3+ Active-Active Datacenters available.
We have a huge set of customers, which we already discussed to back it up as well, where NCache is actively being deployed in Windows & .NET environments So, I think that pretty much concludes today's session. Let me know if there are any questions.
So, I have one question up here Ron for you. Question is phrased in our AppFabric Cache Client Wrapper that we have. We provide all the cluster nodes, ports, timeout settings, etc. via APIs vs in the app.config. Now by using the wrapper, can we provide the same via APIs vs configs?
Yes, you can, because in general, we also have inline parameters, right. So, the wrapper is designed in such a way that it allows you to connect to the cache with minimal code changes and config changes as well. So, that is designed in such a way, right. So, this is why I wanted to make it look like it's very easy option to migrate off. So, we only shown you the config level changes but if you're interested in providing anything inline we have init params. So, we have initialization params, which allow you to provide the list of Servers, Server 1, Server 2, Server 3 ports. So, all that client-side settings that you've seen as part of the client.ncconf which, let me just open right here. So, these are config settings you can specify within the, you know, within the application code as well. So, that is a possibility.
So, one of our attendees is asking about some performance informations. Such as, bandwidth.
NCache is very scalable, it has ability to equip your application to achieve, you know, 100% linear scalability, right. So, you can have more and more servers added and it would just increase the request handling capacity. So, if you just want a general purpose idea, I highly recommend that you review our benchmark. Let me show you this. We have our benchmarks published, with our and you know, Throughput Operations per Second with just 5 NCache Servers, we were able to achieve 2 Million Requests per Second. Right, so, that's something that you can review and you can see from here as well, we just used 5 NCache servers. There's a video demonstration of this as well. So, if you want to review this, there is a whitepaper and then there's a video live demonstration of this test, where we started off with 2 servers and then we were able to achieve some throughput and request handling capacity and then we were able to increase number of servers by putting more and more load. With just 5 node cluster we were able to achieve 2 Million Operations per Second.
So, as far as, Server resources are concerned, if your question is more focused on what bandwidth or server resources are required, these were AWS servers, pretty high-end servers, because we really wanted to demonstrate the capacity or the stretch that you can achieve with NCache. So, we were able to stretch the servers to limits and then we were able to get 2 Million Requests per Second. But you can use a web server kind of configuration as well with up to 8 Cores, with 1 Gigabit Network Interface Card with memory requirements as good as 16 Gigs or more. So, 8 Gigs is fine as well, but 16 Gigs is what we recommend. So, that you have adequate memory, to host your data.
So basically, if I have to give top five reasons, first of all it's .NET versus non-native .NET. Redis is not very compatible with Windows. It has a ported version, supported by Microsoft Open Tech, a third party. Redis Labs or Redis Open Source themselves recommend that you should not use Redis on Windows platform. So, in comparison to AppFabric NCache is a better fit. Primarily, because of being on the same stack as of AppFabric & Redis is not. Redis in general, is more of a Linux based product. Whereas NCache is Windows, as well as, Linux based product.
There are many high availability issues with Redis. Redis cluster is not 100% peer-to-peer architectured, in comparison to NCache. NCache is a fully peer-to-peer architectured cache cluster, where you can bring any server offline. It would not impact your cache clients, which are connected to it and it would not give you any data loss as well. Then a lot of features are missing in Redis. Such as client cache is not there. They've recently introduced it, but it's very basic. We have client cache since 2008, right. So, it's a very old feature, which is very enhanced as part of NCache. Bridge, Server-side code SQL Like Searching, Read-Through, Write-Through handlers, Cache Loader, all of these features are missing in Redis and I would like you to quickly go through a comparison document, which is published on our comparison page. So, you can see Azure Redis vs NCache, Redis vs NCache summary differences, Redis vs NCache (Slidedeck) and then there are, some general purpose information about NCache.
So, let me just show you this real quick and let me know if there are any questions. I'm registered on this, so, let me just sign in. Sure. A follow-up question on that is a, question was on Async Replication.
Can they assume that Async Replications behavior is safe, is it a guaranteed?
It is, it is…., so, you know. If it fails in between, which is a very rare scenario, you can lose that update but it's pretty fast. We have a dedicated thread. Let me show you the diagram and then come back to the first question. So, let's tackle this question first. So, Server 1 active partition, as soon as your application adds something here it returns NCache is responsible for updating it in the backup and there you have async and sync options.
So, async, it's pretty fast. It's within sub-millisecond and I’ll be very happy if you can reproduce a scenario where a call is being triggered on Server 1 and while it was replicating this server goes down and then you're not able to get the update. It's a very rare scenario within NCache. Even our QA teams work really hard to reproduce this and they're not able to do so. So, with slight, with sub milliseconds delay, the dedicated thread updates the backup and while that server goes down, there is a slight possibility that you lose update, but like I said, it's a very rare scenario to reproduce and we have sync option available as well to, to accommodate this situation. If you're very concerned that you need backups to be updated all the time, you can use sync updates, where a client updates the active and backup in one go. It's a transactional operation. If it fails in between, it would roll back the entire operation. So, it's very safe, if your question is focused towards that.
So coming back to Redis, this is Azure Redis vs NCache. So, you can see feature level comparison and you can see the list where Azure Redis have partial role, limited support on all of these fronts. So, high availability is partially supported, cache topologies are limited, WAN replication is very limited, ASP.NET caching features, object caching features, synchronization features are completely missing in Redis and if you're using NCache for object caching, it makes a lot of sense to have these synchronization features available.
The question is: So, I know NCache is native to Windows and compared to Linux Redis is better, however, how does NCache on Linux compare to Redis on Linux?
Same set of features, same support, supported through .NET Core is available on Linux. So, NCache is, it's not just Windows product, in comparison to Redis. Where Redis is mostly Linux oriented product. NCache is Windows and Linux. So, whatever feature set that you're seeing here is fully supported on Linux environment. All the .NET Core releases on Windows, all Linux are at par with one another. We have our custom monitoring, to accommodate the PerfMon counter issue that Linux has, but other than that, all the feature set that you're seeing, this comparison is pretty much valid, everything is valid for Linux environment as well. I'm more focused on Windows, because Redis in general completely lacks, you know, Windows support. But, as far as, NCache is concerned, our Windows offering and Linux offering is exactly the same. So, all the features that we've discussed, debated NCache is a clear winner in Linux environment as well and as a matter of fact with newer deployments, with more customers adopting .NET Core within their applications, they prefer to use NCache on Linux environments. Because, it's more, you know, compatible and more easy to use, from a licensing standpoint, from the Open Source standpoint, Linux is rather easier in comparison. So, our NCache servers, sitting on Linux servers, through .NET Core is a very common practice these days.
Do we have Docker support?
Yes we do, of course. How can we not have Docker support with NCache. If you go to our download page, you would find a section on Docker. We have .NET Core Docker Images, which are available on Linux and then we have .NET Framework Windows and then we have Docker files available for both as well. So, for Enterprise, Professional, Open Source, you can use our, by the way, we intentionally have kept .NET Core Images only for Linux because that's the more common one and as a matter of fact you can use our Docker Images in any Kubernetes platforms as well. Such as OpenShift, such as Azure Kubernetes Service, Elastic Kubernetes Service offered by AWS and Google Kubernetes Service as well. So, it's very common. It's very popular in application deployment. So, it's something which you can download directly from our website or go to the Docker Hub for that matter.
Please confirm, if that answer your question. Let me know if there are more questions. Any others? Even if you can't get all your questions in now, which I’m sure we're getting plenty already but you're always free to email firstname.lastname@example.org. If you have any technical queries or questions about features email email@example.com. Our support team will answer all of your questions, any of your thoughts, use case questions, etc.
And, if you're interested in getting NCache started, well we do have a two month free NCache Enterprise free trial available for you to download and then use in your environment and if you'd like you can contact us either at firstname.lastname@example.org or email@example.com. We'll help you get them set up and also let us know what use cases you're working on? What features you're interested in? We'll make sure that you get a satisfaction on a technical front, absolutely.
We also had a question coming, can we get the presentation slides?
Sure, not only is this webinar recording going to go out, so definitely expect that in your email but we can get the slides out as well, to you specifically. If you'd like or if anyone else wants the slides go ahead and request them now. I'll make sure that everyone gets the slides.
If there are no more questions, then just keep in mind that you can reach out to us anytime. Download NCache Enterprise, if you haven't already and definitely play with it. If you want assistance in getting it set up in your environment, definitely reach out to us.