Support Redis cache [RELEASED]

AdamM

For admins and clients

Using OpenLiteSpeed/LiteSpeed it is possible to use Redis in WordPress using the "Litespeed cache" plugin.
I want to offer it to my clients and I think others will too.
This will also allow to increase the efficiency of servers while reducing costs.
In addition, there is a need for an extension to PHP - Redis

I do not know how exactly to do this.
As an additional role on the server?

I would like to be able to assign Redis in the "Hosting package" for clients, preferably with its own database to prevent deletion of keys by other sites.

Kindly regards

Adam

Hi Adam,

Our plan is to make Redis a package setting which will enable customers to create a Redis instance within their PHP container. They will be able to connect to it on 127.0.0.1 and it won't be shared or accessible to any other website or container.

We will also add the Redis PHP extension as a toggle.

The feature is scoped but is not on the roadmap yet.

If you wanted to use Redis before that you would need to provision Redis manually by either using the Redis docker image or the Ubuntu package. This isn't something I would recommend for production.

Aliysa_Enhance

Adam Our plan is to make Redis a package setting which will enable customers to create a Redis instance within their PHP container. They will be able to connect to it on 127.0.0.1 and it won't be shared or accessible to any other website or container.

Redis is now available in 9.7.0 core https://enhance.com/support/release-notes

AdamM

Great news. I will just wait for it. I prefer to use the solution applied by Enhance team.

mike

waiting for this one too. Redis per website. sounds greats.

george

Great news! Waiting for this one too.

AdamM

@Adam maybe you can try to move it in the roadmap to a sooner date? as you can see a lot of people need it. for scaling hosting is important.

hostxnow

Many ask for it on cPanel/CloudLinux/LiteSpeed platform, but it is not possible at least not to offer it securely without issues.

So, yes, I would like to see this too.

Ned

Relay is another great drop-in provider for Redis - I think the main goal would be getting any Redis support to begin with 🙂

hostxnow
Directadmin has a pretty solid implementation via unix socket - I have been using this for some time with no complaints

AdamM

@Adam
I even think that a better solution for hosting companies would be KeyDB - https://docs.keydb.dev/
KeyDB allows cluster so it would be a great solution for Enhance.
KeyDB is a fully open source database, backed by Snap, and a faster drop in alternative to Redis
I use KeyDB with Plesk and work amazing, personally, I would prefer KeyDB instead of Redis.

About KeyDB

We believe performance ultimately provides freedom to users – KeyDB is fast, provides high throughput out of the box and you don't need to be a database expert to use it. KeyDB does a lot more under the hood enabling you to focus on what counts.
If you had to move to a new house would you rather use a car or a 40ft truck? One method involves careful thought on what you bring and how to pack it in, the other you throw everything in without a second thought and go
This is analogous to the database world when it comes to development. While some databases require sharding and several processes running for a basic setup, KeyBD focuses on extracting maximum performance out of each node. This means less moving parts, and for most workloads removes the need to shard or have sentinel nodes for monitoring. For really large workloads requiring sharding, KeyDB can scale horizontally and with less nodes to provide sub-millisecond latencies.

Our Story

The KeyDB project began in 2019 after creating a multithreaded fork of Redis. We were baffled by the fact it was not fully optimized to take advantage of multiple server cores. We had to run a cluster of nodes on a single machine in order to achieve peak server throughput. The maintainers of Redis had strong convictions to maintain a simple codebase including a single threaded engine, and had turned down some great community requests as a result. While we loved Redis, we had a very different philosophy on how the codebase should evolve. We felt that ease of use, high performance, and a “batteries included” approach is the best way to create a good user experience, even if it adds complexity to the codebase. Because of this difference of opinion, features which are right for KeyDB may not be appropriate for Redis. We work hard to ensure compatibility with upstream Redis, while building out functionality in KeyDB that we think is necessary for users to succeed given the challenges of today.

When we introduced KeyDB’s multithreading and MVCC architecture, we had orders of magnitude increase in single node throughput. We have since continued to squeeze out every ounce of performance in the design of KeyDB to become a leader in performance. Our architecture has enabled us to design features, commands and configurations that provide powerful tools to users without performance penalties. Since KeyDB began we have added support for non-blocking queries, FLASH storage, subkey expires, and others. We will be supporting additional data structures, and configuration options as we continue to grow.

As KeyDB grew and we started to monetize we were always torn between what features to open source and which ones were needed to monetize and support the company's growth. In 2021 we were approached by Snap Inc. with the opportunity to bring KeyDB to a company that operates at a magnificent scale. At this time we discovered Snap wanted to open source everything to share and collaborate with the community while KeyDB continued to develop as a major part of the backend caching layer at Snap! At the end of 2021, KeyDB found its permanent home at Snap Inc.
A Home at Snap#

We were so excited to join the Snap team at the end of 2021. Not only would we get to work under the hood and power some of the largest workloads, but we would get to share all our advancements with the community (including what used to be our monetized offering)! Snap wanted to open source our entire codebase to collaborate and develop with the open source community. They understood that many hands are better than fewer, and a diversity of workloads and super talented community developers will help drive KeyDB to be the best product it can be. Maintaining only one community offering also meant that our team could focus on what we do best, writing high performance database code!

Since our time here at Snap we were so happy to find that they really live by their values and we are excited to be working at such a great company. For anyone who is interested in joining the Snap team, they are hiring and we encourage you to apply.

Our Team

KeyDB maintains a team of C++ developers (including all original developers) to continue building the open source project, and has also expanded to bring in Snap engineers who are highly experienced developing applications at scale."

kyzoeadmin

AdamM that looks amazing. I support the idea of Keydb instead of Redis.

necrom

AdamM It would be idea to support the choice of either, I would probably use KeyDB but call it Redis* as some users don't like to deviate from a named product even if the drop-in is seamless. The choice would allow me to revert back to true-redis if they ever went in more different directions.

prasad0889

@necrom That is a good idea.

AdamM

@Ned but Relay is limited in free version, Redis or KeyDB not.

digitalexpanse

We also use Redis on socket and we're killing it. Never heard of KeyDB or Relay and fine with either provided they play nice with LScache which currently supports Mem/Red.

KeyDB - drop in redis replacement?
Relay - drop in redis replacement?

Ned

[unknown]

Yes, I agree paid option is not great but for my needs, it's quite good, I do plan on having a look at KeyDB also!

The main thing to keep in mind KeyDB and Relay are both drop-in replacements, I am trying to show that there are lots of options that people like so that when the Enhance team does look at Redis they can see that drop-in replacements are something people plan to use so they can support them, write some documentation or even give us an easy way to pick between the three.

[unknown]

Yes, Both are drop-in but with enhance it may be a bit tricker as they are using everything in docker containers, so bringing these up for consideration to the devs is important so they know what the community is using/want.

Redis & LSCache is great, My current setup on DirectAdmin - I use relay on more niche sites which warrant it.

AdamM

@Adam Is it possible to add redis/keydb to roadmap? This topic is the most popular on the forum. Many customers expect this. This will increase efficiency and minimize infrastructure costs.

John-P

Agree with all of the above, no real preference between Redis and KeyDB, but having one of them integrated would be a huge plus.

Adrien

This is a great news. Customers Having Redis running within their php container and not being shared.
I support this feature and prefer that it is being well implemented then rushed.
So I'll be waiting patiently.

AdamM

After update Appcd 1.1.0 redis-php is available.
question now how to run e.g. docker redis image or keydb to be able to connect to wordpress sites and litespeed cache plugin?
Does anyone know how to do this correctly?

ss88us

AdamM Now that redis is available via the PHP module the LiteSpeed cache plugin will work but you still need to install redis on the server.

apt install redis will work and this should work for docker. I will be trying docker later and can let you know.

Darren

The redis-php module enables PHP to talk to a redis instance. There's no reason why you couldn't run a docker container of redis on the same server (e.g. docker run --name my-redis -p 6379:6379 -d redis) - however at the moment Enhance provides no management or monitoring of that instance, so you'd want to make sure it was monitored and you're comfortable managing the container/redis config files. So right now it's possible if you know what you're doing, but it's 'at risk'. It also won't be isolated in any way from other sites on the same server, so possibly not great on a shared system.

In the future as Adam has mentioned we are looking to provide a way to offer redis within each appcd container on a per site/per package basis which will isolate the redis from other users as well as monitor and restart if any issues etc.