Hi everyone, hi @VirtuBox,
I have been using WordOps for about 6 years on production servers (currently one server
with 21 sites, 12 of them WordPress with --wpfc). Over time I have found a few issues
that come up on all my sites, and I would like to propose fixes upstream instead of keeping
local patches.
Before opening pull requests I would like to follow the project's workflow:
- Target branch: should PRs go to
master, or is there a development branch
(develop/beta look inactive and updating-configuration seems to be a maintainer branch)?
- Process: do you prefer an issue (or a forum thread) first to discuss the idea, or
a PR directly? One PR per topic?
- Testing: what do you expect before review (distributions/versions to test,
wo stack upgrade on existing installs, CHANGELOG entry)?
What I would like to propose first, all about the FastCGI cache:
- Store the cache on disk instead of tmpfs. The default 256 MB in
/var/run was full
within hours; with 2 GB on disk the share of requests served from cache roughly doubled on
most sites. /var/run/nginx-cache stays as a symlink, so nginx-helper keeps working.
- Ignore campaign parameters in the cache key (
utm_*, gclid, fbclid...) only when
they are the only parameters. Today every ad/social click misses the cache.
- Stop caching errors (
fastcgi_cache_valid any 1h and 499 502 503 1m): a transient 500
was served to other visitors for up to one hour.
- Optional, disabled by default: per-site cache zones, so a nginx-helper "purge all" on
one site does not empty the cache of every site on the server.
The changes are already written and tested on Ubuntu 24.04 and in production, with
measurements before and after. I am happy to adapt them to whatever direction you prefer.
Thanks for maintaining WordOps!
