One last topic that's not quite clear to me is persistent connections, in general and specifically also with Relay
As you noted, Relay defaults to using persistent connections, since Redis uses the connection itself to manage which keys the given client may have cached. Whenever the socket disconnects (either manually, or as a result of an error), Redis will clean up its database of our cached keys, and Relay will also flush its in-memory cache.
I'm don't quite understand if there's a downside to persistent connection and if there are cases where they should not be used, specifically also with the other clients).
With a typical setup there's really no downside to persistent connections, and would be harmful to the performance of client key caching. That said, they can be disabled by default with the relay.default_pconnect ini setting. This could be useful if Relay's in-memory cache was disabled.
We still have `pconnect` and `pclose` mostly for compatibility, but also so connections can be actually closed without having to restart fpm.
Hi Berdir, I'm writing Relay with Till.
Relay will cache non-existent keys, but I think you're running into edge cases.
- Relay doesn't cache `nil` replies in `MGET` because technically this could mean the key doesn't exist, or it's a key of a different type. It would be quite easy to add that as an option if it would be useful.
- Relay won't read from the in-memory cache inside of `MULTI`..`EXEC` blocks. The reasoning is that we can't provide the same atomicity guarantees that Redis can for transactions. This could also be made into an option if that would be useful.
Cheers!
Mike