Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nginx config suggestion for redis page cache (and the future) #754

Closed
pjv opened this issue Jul 30, 2016 · 7 comments

Comments

@pjv
Copy link
Contributor

commented Jul 30, 2016

When you create a site with ee using the redis page cache, the files common/redis*.conf create a $key macro for writing to the redis cache that includes the hard coded prefix nginx-cache:. That string corresponds with the default value in the nginx-helper settings for redis page caching:

2016-07-30 at 5 56 am

That causes the problem on a host that handles many different domains that when you use the nginx-helper's "purge cache" option, you not only purge the page cache for the site you are working with, you purge the entire page cache for every site that uses the default nginx-cache: prefix string.

If you want to change the prefix in the plugin settings on a domain by domain basis so that you can purge the page cache for one domain at a time, you also have to make the corresponding edit in the common/redis*.conf file that you are using and that is a file that an ee update will overwrite and hose your modification.

I suggest making the following changes in ee:

  1. in the common/redis*.conf files, instead of hard-coding the string nginx-cache:, use a macro like this:

    set $key "$redis_prefix$scheme$request_method$host$request_uri";

  2. in the sites-available vhost config for a given site, define that macro initially like this:

    set $redis_prefix nginx-cache:; # if changed, also change in nginx-helper settings

Then you can change the $redis-prefix string in the vhost config and in nginx-helper and successfully separate the page caching from one vhost to another. I have tested this and it works as expected.

It would also be good to put some documentation in the nginx-helper plugin about the necessary nginx configuration to make use of the Prefix setting.


Tangentially, I have been thinking a lot about how to make it possible to customize various nginx configurations while staying compatible with ee updates and it seems to me that the approach detailed above, where you define a macro in the vhost configuration file under sites-available and then use that macro in the common/*.conf files that are over-written on an ee update might be a workable pattern.

What I have been doing in the mean time is creating my own custom directory next to common and then copying the files I want to modify from common to custom and then in my vhost configs, I change the include path from common/*.conf to custom/*.conf. This obviously gets me out of sync with ee updates and will force me to manage stuff by hand in the future as files under common change with ee updates.

Would be a lot nicer if nginx let us do conditional includes so that we could instead override the common/*.conf files by putting like-named files with customized fragments under the /var/www/vhost/conf/nginx/ path, but unfortunately nginx's configuration system does not allow this.

@pjv

This comment has been minimized.

Copy link
Contributor Author

commented Aug 4, 2016

crickets, really?

@zorrobyte

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

I would recommend sending in a Pull Request. I had a Redis related change regarding cache type and it was merged in a few days.

@pjv

This comment has been minimized.

Copy link
Contributor Author

commented Aug 8, 2016

Implementing this idea even in the specific use-case I outlined above would be a significant project. Including maintaining backward compatibility for those with existing ee installs makes it critical to get it right. So I think this has to be a job for core ee developers who know the future roadmap well to take on. I'm just suggesting one possible approach for the future.

Any thoughts on this idea, @rahul286 ?

@rahul286

This comment has been minimized.

Copy link
Member

commented May 29, 2018

Related to #1015

@rahul286 rahul286 added this to the 4.0 - PHP milestone May 29, 2018

@rahul286 rahul286 added this to In-Progress in v4 First Release May 31, 2018

@rahul286 rahul286 modified the milestones: 4.0.0, 4.0.0-beta.2 Jun 1, 2018

@pjv

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2018

i'll reiterate this suggestion and say that i have been using it in production since the OP above almost two years ago and it works fine. I can host multiple sites on a given server, give each one their own page cache $redis_prefix and flush them from the cache independently of each other.

@rahul286

This comment has been minimized.

Copy link
Member

commented Jun 22, 2018

@pjv wondering if this will be relevant in EE v4.

Each site will have its own redis container. So prefix collision wont happen.

I am closing this issue for now. Happy to reopen and look further into it, if I missed something.

@rahul286 rahul286 closed this Jun 22, 2018

v4 First Release automation moved this from In-Progress to Done Jun 22, 2018

@pjv

This comment has been minimized.

Copy link
Contributor Author

commented Jun 22, 2018

@rahul286 that sounds like an interesting plan. I wonder from a resource usage point of view what it will cost (memory-wise, mostly) to have multiple redis containers running simultaneously vs. a single redis instance that is used by all sites hosted on a server.

if the overhead of running a redis container per site is not too burdensome, then it would definitely make my hack unnecessary and simplify things a lot, so great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.