Should Redis be configed as a cache server or not?

Support Self-hosting

AI-generated summary

The discussion revolves around whether Redis should be configured as a cache server or not, specifically in the context of Discourse installation. louirobert quotes the official Discourse GitHub page and Sidekiq’s documentation, which have conflicting recommendations.

louirobert is currently using a single Redis instance configured as an LRU cache and is seeking advice on whether to create another instance for Sidekiq. codinghorror mentions that Redis flushes are not ideal but not catastrophic.

The conversation takes a turn when Falco points out that the only officially supported Discourse installs are Docker-based, but louirobert explains that Docker is not suitable for their use case in China due to network blockages and slow image downloads. Instead, they use Capistrano for deployment.

The discussion then shifts to finding workarounds for the network errors encountered during installation. Falco and fantasticfears suggest using mirrors or proxies, such as RubyChina mirror, to resolve the issue. louirobert thanks the community for their help and decides to continue using their current Capistrano deployment.

1

The official GitHub page for Discourse says

“We use Redis as a cache and for transient data.”.

But Sidekiq, which is a part of Discourse, says

“Many people use Redis as a cache but it’s important that Sidekiq be run against a Redis instance that is not configured as a cache but as a persistent store.”

and it also suggests

“using two separate Redis instances, each configured appropriately, if you wish to use Redis for caching and Sidekiq”

So what should I do? I currently have only one Redis configed as a LRU cache. Should I make another one for Sidekiq, and how? Or I can safely ignore Sidekiq’s suggestion?

Thanks.

2

Are you trying to install Discourse for production use? If so, simply follow these instructions:

3

In general we try to avoid Redis flushes, but it’s not completely the end of the world if it does get flushed. Worst case, some emails might not get sent such as password resets and users will need to re-request.

4

I’m not using Docker. I deployed it through Capistrano. It’s production.

5

Just for info, on the forums:

The only officially supported installs of Discourse are the Docker based beginner and advanced installs. We regret that we cannot support any other methods of installation.

7

Yes, I know that. But for Chinese users, Docker is not a good choice: it’s intended for convenience but due to the network block(GFW) from within China, bundler install fails frequently for network error. So Chinese Docker user has to manually edit the Docker templates and configs and so on to fix that. It’s not easy, not to say that the Docker image download is VERY SLOW in China, and I’m afraid someday it may be totally unavailable. So a workaround for me is to use bundler package to avoid network download for installing Ruby Gems, which I’ve prepared in some special way before. In short, I need a way with highly custom installation script and Capistrano fits me. Rather complex, right?

8

I am pretty sure @fantasticfears had a workaround for this.

9
12

Thanks. However I tried Taobao mirror before, that doesn’t always work: Gems of required(new) version had been missing for 1+ months because the mirror server stopped syncing with official source for unknown reason. Here is an example: Could not find email_reply_trimmer-0.1.1 in any of the sources · Issue #50 · alibaba-archive/ruby.taobao.org · GitHub
Taobao mirror is not always reliable.

13

Thanks but @fantasticfears’s solution depends on Taobao mirror, which is not always reliable. Please see my previous reply for details.

14

It’s been moved to RubyChina mirror. I documented them here and there in Chinese.

You have more than one way to fix this, either by mirrors or by proxy. If you have a reliable proxy, you don’t even bother whether a mirror is perfectly stable to you. Besides, RubyChina mirror is rather stable comparing to the launch. Issues · ruby-china/rubygems-mirror · GitHub

Docker can also employ a proxy as described in the documentation.

If you are using Capistrano, you have more choices since you are a senior developer.

15

Thanks! I’ll look into the Docker solution again when I have to turn to it. For now, my Capistrano deployment has been working well. Thanks for all your help!