prometheus_client_php icon indicating copy to clipboard operation
prometheus_client_php copied to clipboard

Document RedisNg

Open mvhirsch opened this issue 1 year ago • 4 comments

Hey @LKaemmerling ,

I'm using the artprima/prometheus-metrics-bundle Symfony bundle (which is built on this library) and need to add \RedisCluster support. Currently it fails connecting to multiple hosts (like a redis-cluster). I also noticed lack of predis support in #79. Well, I cannot add support for redis, but need to add support for \RedisCluster.

Starting to taking a deep look at this code, I noticed an undocumented RedisNg which you already suggested as (production-ready?) to ppl: #92, #98, #105. Looks like it's the next generation (focus on performance), but backwards-incompatible to Redis, is it?

Could you please share some thoughts on this, so I could propose a documentation/PR?

Thank you in advance!

mvhirsch avatar Apr 22 '24 10:04 mvhirsch

RedisNG is basically an more optimized version of Redis. It contains a few breaking changes compared to the old Redis Storage.

LKaemmerling avatar Apr 23 '24 20:04 LKaemmerling

https://github.com/PromPHP/prometheus_client_php/pull/99

LKaemmerling avatar Apr 23 '24 20:04 LKaemmerling

Thank you for answering.

RedisNG is basically an more optimized version of Redis. It contains a few breaking changes compared to the old Redis Storage.

I see, so it's safe to use it (production-ready)?

Question is: supporting both (Redis and RedisNg) will add more maintenance load over time. What's your current plan on this? Will there be a v3 dropping support for Redis and only go for RedisNg? If so it does make sense (at least to me) to build support for more Redis variations on that:

  • #153
  • #95
  • #127

Is it possible to create a migration-script or upgrade guide for users switching to new RedisNg? That said it might be a chance to get rid of some legacy and win more support with less maintenance work.

mvhirsch avatar Apr 24 '24 08:04 mvhirsch

Currently, it is not planned to remove the old Redis storage, however, it might make sense as you mentioned. Adding support for more redis variations makes sense IMHO. I'm not sure if this would make sense to build everything into one big Redis Adapter or if there should be a dedicated adapter for every variation.

RedisNG is production ready, a migration guide is not quite possible, it is as simple as "drop the whole content of all Redis Keys", they should not be used together.

(Same goes for APCng)

LKaemmerling avatar Apr 24 '24 09:04 LKaemmerling