Am reading people having trouble with using rediscache in azure functions on consumption plan.
please advise best practice for using caching in azure functions 2.0
my rediscache will be used by api's as well as azure functions (consumption plan). since connection object is supposed to be singleton and reused in case of functions on every request it will create new connection will this create problems ?
Please be aware of the various limitations for Azure Redis Cache performance per pricing tier, especially SSL and Non-SSL connections per second. Please also be aware of the benefits + behaviors of using the StackExchange.Redis configuration options.
Related
We are analyzing ignite to use it in .NET platform, In Ignite document we can see there is some limitation on running cluster in Java and Thin Client in .NET. The list provided in the document doesn't mention about "Data Streaming". So would like to know whether "Data Streaming" is supported in "Mixed-Platform" or not ?
Yes, Data Streaming is supported in mixed-platform clusters, and you can do it from Ignite.NET Thin Client without any limitations.
P.S. The document is slightly outdated (fix on the way), Services are also supported in this scenario, you can make Java <-> .NET service calls in both directions, which some customers use extensively:
https://ignite.apache.org/docs/latest/net-specific/net-java-services-execution
We are using kong api gateway as a single gateway for all apis. we are facing latency issue with few of our api's (1500-2000ms). later when we checked, latency was being created because of the "rate limiting" plugin. When we disable the plugin, latency improves and the response is same as what we get directly from IP (close to 300ms approx).
I m trying to setup redis node to cache database queries, I m not sure how we can configure kong to read from redis itself. how we can cache the database queries to redis node.
We are using postgresql for kong.
I think maybe you are trying to do a couple different things at once.
First, rate-limiting: what is the value for your config.policy parameter? The Kong documentation has three values: "local (counters will be stored locally in-memory on the node), cluster (counters are stored in the datastore and shared across the nodes) and redis (counters are stored on a Redis server and will be shared across the nodes)."
If you are seeing high latency, and your config.policy is set to cluster or redis, it might be due to latency between Kong and postgres/redis (depending on what policy you're using). If you are using rate-limiting just to prevent abuse, using the 'local' policy is faster. (There's more about this at the Kong documentation.)
The other question is about caching: Kong Enterprise has a built-in caching plugin, but for Kong Community, since it's built on top of Nginx, you can do caching with Nginx. This link might help you.
There is a community custom plugin out there that enables the use of caching with redis without the need to use the Kong Enterprise -> https://github.com/globocom/kong-plugin-proxy-cache
Maybe you could combine that with rate limiting to achieve the desired latency performance or use this plugin as inspiration.
I was wondering about how deepstream decides to store an info in cache vs database if both of them are configured. Can this be decided by the clients?
Also, when using redis will it provide both cache and database functionality? I would be using amazon elastic cache with redis backend for the same.
It stores it in both, first in the cache in a blocking way and outside the critical path in the database in a non-blocking way.
Here's an animation illustrating this.
You can also find more information here: https://deepstream.io/tutorials/core/storing-data/
This is my first question in this forum, so kindly forgive me for my mistakes.
Now, my query is regarding clustering in Netty Server 4.0.
We have one solution which was designed and developed in Netty Server. That time it was using multiple instances in a way so that clients were not effected if the sessions are not shared among them.
Now, in a different project while using the same solution we have come across a situation where we need to share and synchronized the JVM within multiple instances. Since, netty itself does not support JVM level clustering we are looking for a framework which will support Netty to run in cluster mode.
We are not supposed to put lot of efforts in re-writing the Netty Server code and other business login as it is serving the same purpose but we are looking for a configuration based framework to support clustering with Netty Server.
Some configuration based tutorial are really appreciated.
Thanks in advance and looking forward for responses.
Regards
Sid
So, in my WCF service, I will be caching some data so future calls made into the service can obtain that data.
what is the best way in WCF to cache data? how does one go about doing this?
if it helps, the WCF service is multithreaded (concurrency mode is multiple) and ReleaseServiceInstanceOnTransactionComplete is set to false.
the first call to retrieve this data may not exist therefore it will go and fetch data from some source (could be DB, could be file, could be wherever) but thereafter it should cache it and be made available (ideally with an expiry system for the object)
thoughts?
Some of the most common solutions for a WCF service seem to be:
Windows AppFabric
Memcached
NCache
Try reading Caching Solutions
An SOA application can’t scale effectively when the data it uses is kept in a storage that is not scalable for frequent transactions. This is where distributed caching really helps. coming back to your question and its answer by ErnieL, here is a brief comparison of these solutions,
as Far as Memcached is concerned, If your application needs to function on a cluster of machines then it is very likely that you will benefit from a distributed cache, however if your application only needs to run on a single machine then you won't gain any benefit from using a distributed cache and will probably be better off using the built-in .Net cache.
Accessing a memcached cache requires interprocess / network communication, which will have a small performance penalty over the .Net caches which are in-process. Memcached works as an external process / service, which means that you need to install / run that service in your production environment. Again the .Net caches don't need this step as they are hosted in-process.
if we compare the features of NCache and Appfabric, NCache folks are very confident over the range of features which they ve compared to AppFabric. you can find enough material here regarding the comparison of these two products, like this one......
http://distributedcaching.blog.com/2011/05/26/ncache-features-that-app-fabric-does-not-have/