I am currently working on a ASP.NET MVC application.Currently it is using AppFabric for storing session and cache data.But Microsoft has stopped support for AppFabric.Microsoft is using Redis for cache management and is supported by Azure.
What is the difference between AppFabric and Redis in terms of speed,size of data and performance?How Redis is different than AppFabric?
According to the following post, "Mainstream Support will be provided until 4/11/2017 and Extended Support until 4/12/2022."
http://blogs.msdn.com/b/appfabric/archive/2015/06/19/appfabric-1-1-for-windows-server-support-lifecycle-extension-4-11-2017.aspx
This means you are not without support yet. However, Microsoft does recommend that all application using AppFabric should migrate to Redis Cache. See this entry in MSDN for Cache Recommendations.
https://msdn.microsoft.com/en-us/library/azure/dn766201.aspx
How is Redis better/different than AppFabric...
First, AppFabric was actually contained a number of technologies including, Service Bus, Access Control Service, and Caching
see also: Azure AppFabric vs. Server AppFabric - today
Second, from a caching perspective, AppFabric was more closely aligned with .Net. Redis as an Open Source NoSQL database store is usable by a broad set of technologies including Python, Ruby, Java, PHP, Node, C, C#.
Third, since its keys can store data structures like strings, hashes, lists, sets, sorted sets, bitmaps, and hyperloglogs, it is generally more flexible than other caching solutions.
There is a migration guide here, if you want to see what might be involved with moving to Redis Cache.
https://msdn.microsoft.com/en-us/library/azure/dn690524.aspx
Related
Currently, My web application is on Redis db(all database). it's required more than 4 GB RAM which is cost me a lot.
I want to migrate some part of my application into permanent storage DB(SQL, mongo...)
So, Can anyone tell me which is the best choice(SQL, mongo...)?
Technology stack of my application:
nodejs(express)
angularjs
redis
It really depend on your design. Is your data highly relational? Redis is considered a NoSQL technology so I guess MongoDb would be somewhat similar but implementation will be file-based instead of key-value set. If you need your data to have strong relationship between each data set then SQL family is designed for exactly that, but a lot of work is needed to build the tables first and then separate the data.
There is a need to cache objects to improve the perf of my Azure function. I tried .NET ObjectCache (System.Runtime.Caching) and it worked well in my testing (tested with upto 10min cache retention period).
In order to take this solution forward, I have few quick questions:
What is the recycling policy of Azure function. Is there any default? Can it be configured?
What is the implication in the cost?
Is my approach right or are there any better solutions?
Any questions that you may know, please help.
Thank you.
Javed,
An out-of-process solution such as Redis (or even using Table storage, depending on the workload) would be recommended.
As a rule of thumb, functions should be stateless, particularly if you're running in the dynamic runtime, where scaling operations (up and down) could happen at any time and your host is not guaranteed to stay up.
If you opt to use the classic hosting, you do have a little more flexibility, as you can enable the "always on" feature, but I'd still recommend the out-of-process approach. Running in the classic mode does have a cost implication as well, since you're no longer taking advantage of the consumption based billing model offered by the dynamic hosting.
I hope this helps!
If you just need a smallish key-value cache, you could use the file system. D:\HOME (also found in the environment variable %HOME%) is shared across all instances. I'm not sure if the capacities are any different for Azure Functions, but for Sites and WebJobs, Free and Shared sites get 1GB of space, Basic sites get 10GB, and Standard sites get 50GB.
Alternatively, you could try running .NET ObjectCache in production. It may survive multiple calls to the same instance (file system or static in-memory property). Note, this will not be shared across instances though so only use it as a best effort cache.
Note, both of these approaches pose problems for multi-tenant products as it could be an avenue for unintended cross-tenant data sharing or even more malicious activities like DNS cache poisoning. You'd want to implement authorization controls for these things just as if they came from a database.
As others have suggested, Functions ideally should be stateless and an out of process solution is probably best. I use DocumentDB because it has time-to-live functionality which is ideal for a cache. Redis is likely to be more performant especially if you don't need persistence across stop/restart.
What is Azure REDIS Cache? How to use it? When to use and when not to use it? Can I use it for a simple c# application which accesses data from MS-SQL server?
What is best source to get started with Azure Redis cache?
Azure Redis Cache offering is a Software as a service (SAAS) offering of the opensource Redis cache. You should be able to get started with the resource below:
https://azure.microsoft.com/en-in/services/cache/
https://azure.microsoft.com/en-in/documentation/services/redis-cache/
http://redis.io/documentation
There is good support for C# via 'StackExchange.Redis' nuget package. However, please explore if your application needs or will benefit from a cache solution before you get to the implementation.
Azure Cache for Redis provides an in-memory data store based on the Redis software. Redis improves the performance and scalability of an application that uses backend data stores heavily
In my application I have stored around 5 millions key/value data with each key containing around 800 records in json format under Redis cache. Called the Redis using stackexchange library(1.2.6) since the application does not support the latest version
You can go through the below links
https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-overview
https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-redis-samples
Is there an easy way to manage offline data with a web app, and synchronize with a server when there is a connection? I have been looking at Meteor, CouchDB and the likes, but still not sure what would be the least painfull way.
I could of course implement it myself with sockets or something similar, but if something is already made for the purpose, I don't see a reason to do it again.
I'm planning to work with Node as the server.
Thanks
You're talking about two things; 1) How to store/persist data if/when offline (storage mechanism), and 2) How to synchronize with a server when online (communication mechanism). The answer to 1 is some kind of local storage, and there any several ways of doing that (localstorage, websql, filesystem APIs etc) depending on your platform. The answer to 2 really depend on how urgent your synchronization needs are, but in general you can use HTTP itself with periodic (long-) polling, websockets and similar.
On top of both storage and communication mechanisms there are numerous libraries that make the job simpler, like Meteor (communication) and CouchDB (storage), but also many many more. There are even libraries that take care of the actual synchronization mechanism (with possible conflict resolution as well), but this very much depends on your actual application.
Updated: This framework looks promising, but I haven't tested it myself:
http://blog.nateps.com/announcing-racer-experimental-realtime-model
You might want to look at cloud services as well. These are best if you are developing a new application as they push you more to a serverless model, and of course you have to be happy using a service.
Simperium (simperium) is an interesting cloud service - the only one I can find today that does syncing (unlike Firebase and Spire.io who are similar in other respects), and for iOS it includes offline storage, while for JavaScript clients you'd need to cover the local storage yourself using HTML5 features. Backbone.js seems to have some support for this, and Simperium can integrate with Backbone, using a similar API style.
For non-cloud services, Derbyjs (derbyjs) is an open source project that includes Racer, a data synchronization library (mentioned by the earlier answer) - both are under rapid development and not yet complete, but look interesting if your timescales allow, and don't require a cloud service. There is a comparison of Derbyjs to Meteor that is useful - although it's written by the Derbyjs developers it's not too biased.
I also looked at CouchDB, which has some interesting built-in replication features, but I didn't like its use of indexes that are updated lazily when a query needs them (or by a batch process), and I wasn't happy with exposing the server DB directly to clients to enable replication/sync. Generally I think it's best to decouple the client side local storage from the server side DB, and of course for a web app it would be hard to use CouchDB on the client.
I'm working on Integration project where third party will call our web service in Azure. For performance reason I would like to store 2 table data (more than 1000 records) on to the app fabric cache.
Could anyone please suggest if this is the right design pattern?
Depending on how much data this is (you don't mention how wide the tables are) you have a couple of options
You could certainly store it in the azure cache, this will cost though.
You might also want to consider storing the data in the http runtime cache which is free but not distributed.
You choice would largely depend on the size of the data, how often it changes and what effect is caused if someone receives slightly out of date data.