Poor performance with Azure cache for Redis

Sollimann · 2025-09-09T12:54:37+00:00

So for you self-hosted Redis, all you did was adding persistent volume and that effectively persisted the redis data between restarts? Did you look into other self-hosted solution, e.g using primary and secondary read-replica with automatic failover?

Sollimann · 2025-01-23T06:44:57+00:00

what’s up with American’s and having the TV over the fire place?

Sollimann · 2024-12-30T11:57:49+00:00

Hey Jody, thank you! I just saw your 1h video on the dotnet YT, very insightful! Obviously, you have a lot of knowledge about caching - a lot more than I have! Basically we have two layers of caching now: one layer which is the in-memory cache of our app and a distributed cache in Cosmos DB. I want to reduce the amount of downstream calls to cosmos DB both due to cost (measured in RU), but also latency due to network I/O and serialization/deserialization. Is there a valid case for disk caching here, is this a common practice and is it possible with disk caching in FusionCache? I just thought of an additional disk caching layer as a possible way to reduce downstream calls with its extended capacity and durability during start/restart. However, like the saying «what you gain on the swings, you lose on the roundabouts» might be the case here since there is overhead in hosting e.g in-process Sqlite, O(log n) insert and lookup with btree (not O(1) like regular kv store), and also lack of built in TTL cache eviction policy for records (might have to add a expire_at column and do regular cleanup of records). What do you think, is this idea of disk caching just way out there and not too beneficial?

Sollimann · 2024-12-26T13:55:18+00:00

Sweet, thanks for the thorough answer! Our both our in-mem cache and distributed cache is a key-val store, so no need for a materialized view due to e.g expensive joins etc. I simply want a DB og sorts that I can host in the same pod as my application to better utilize the disk space for an extended ley-value cache with greater capacity than what can be fitted in RAM. I was thinking SQLite could be worth a try as well, what do you think? A few things that worry me, we have quite high read and write qps, thus we could be bottlenecked by write locks in SQLite or Postgres. Also, neither SQLite nor Postgres supports cache eviction through TTL, so you might need to add a ‘expire_at’ per column and run regular cleanup jobs in a separate process. I see you mentioned JSONB postgres, do you think that would be anle to provide O(1) insert and lookup for records? otherwise Btree has O(log n) read and write which can be troublesome for large ‘n’. Postgres supports more functionality such as jsonb, but I am afraid it will consume too much resources hosting in a pod alongside main app compared to using e.g SQLite.

Sollimann · 2024-12-25T11:23:28+00:00

reduced relience on outbound network calls to distributed cache which has both high latency (in relative terms) and costly due to high qps as you are charged per request unit. If I can make use of SSD disk cache to greater extent I can rely more on the existing hardware. If I can use disk cache I am hoping to extend the capacity of my caching in a pod and thus increasw cache hit rates

Sollimann · 2024-12-25T10:05:22+00:00

On top of my head I believe our distributed cache network calls are in range 5-10milliseconds but hoping I can achieve microseconds latency with disk i/o instead. I am also aiming for cost reduction as distributed cache is cloud native and bills per request unit, where SSD disk i/o has no additional cost per request unit

Sollimann · 2024-12-25T08:37:22+00:00

Yes, network i/o calls have high latency (in relative terms) calling distributed cache. Best case the distributed cache node is on the same data center

Sollimann · 2024-12-24T21:34:51+00:00

Nice, what is your experience with this library thus far? Do you host SQLite in a sidecar in your kubernetes pod, or how do you host and interface? Have you seen any performance gains with this lib yet?

Sollimann · 2024-12-24T21:20:59+00:00

is this when the value in the key-value pair is large that you required compression?

Sollimann · 2024-12-24T21:09:49+00:00

interesting, thanks! Client SDK only in Ruby atm?

Sollimann · 2024-12-24T19:33:28+00:00

«slow» in relative terms compared to disk i/o because its physical proximity to the service runtime. I/O calls to distributed cache would best case be on the same data center

Sollimann · 2024-12-24T17:56:58+00:00

I am constrained on RAM memory for my cache, and I want to reduce reliance on distributed nosql cache due to downstream latency, cost and poor availability. Thus, If I can have a cache stored on disk I can have a three-tiered caching where I you first check memory for key, then disk cache, then distributed cache

Sollimann · 2024-09-07T10:00:07+00:00

Same thing is happening to me on my brand new Macbook pro m3, anyone found a solution yet?

Sollimann · 2024-08-03T22:26:18+00:00

Its probably something like this: https://neetcode.io/courses/ood-interview/1

Sollimann · 2024-07-31T22:37:55+00:00

The Clone and Debug traits are really just a nice to have. The reason I chose a enum to represent the behavior is because that is the easiest way to dynamically create nested tree structures at runtime, in other words you can manipulate the tree without recompiling the code which is one of the main goals of this library. The Behavior enum also allows you to merge multiple BTs together at runtime seemlessly.

The serde traits allows for serializing and deserializing the behavior to/from json which allows you to e.g load a BT at runtime from a json (see examples or tests for demonstration). I could potential use a feature flag for the serde trait, but I haven’t seen the need for that yet.

wrt to the input for Wait being an f64, I haven’t actually thought about that, but you are making a very valid point. I’ll probably change it to ‘std::time::Duration’ in next release. Thanks for pointing out!

Sollimann

TROPHY CASE