• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Varnish (in Docker) not working with 301 to https

Martin.H

Regular Pleskian
I implemented Varnish like described there:

Varnish for WordPress in a Docker container in Plesk Onyx

It is indeed working, but when I activate the 301 SEO redirect to https it gives me this error "ERR_TOO_MANY_REDIRECTS".

Does anyone know how to fix this?
If I disable 301 to https it is working but content gets loaded from http which is breaking the SSL certificate.

Pls do NOT provide solutions just for Wordpress etc, as I will use this Varnish Cache also for Drupal and Typo3 and on every Domain I activated the 301 to https.

I would like to get it work like this:
Nginx --> Varnish (in Docker) --> Apache

I'm running Plesk 17.5.3 in the latest version on a Debian 8.10 Server.


Thank you in advance!
 
Hi Martin,

frankly I do not understand, why you would want to use Varnish, when you have nginx running as edge server. Nginx is actually as fast as Varnish as a reverse proxy (imho faster) and definitly faster than Varnish under load (190,000+ SSL parallel connections at 4core XEON, 16GB, intel GB NIC - see nginx.org ), can handle more connections and integrates smoothly with Plesk http and https, while using less memory. Also nginx performance can be further increased with a redis-based cache, which actually makes nginx much more efficient and faster than Varnish.

If you are not that apt with nginx and look for Microcaching, you should just go for the Onyx Beta (17.8.9 or something).

Just from my perspective:
- Plesk web configuration "sucked" in speed and efficiency for a long time, while staying in Plesk vanilla configuration.
- With 17.8.9 Plesk can be configured lightning fast out of the box. In fact you are able to build the fastest possible hosting environment this way, able to hold a large amount of parallel connections.
- Adding Varnish only increases complexity, memory consumption, CPU consumption, slows down the site configuration and adds security holes.

So considering the last point, my question: why would you add Varnish? Or is there a specific need you didnt mention?
 
hi martin

can you explain how nginx can be used to replace varnish? I cant see how it can cache rendered php processes.

on another note does anyone know the answer to the OPs question?
 
Hi Martin,

frankly I do not understand, why you would want to use Varnish, when you have nginx running as edge server. Nginx is actually as fast as Varnish as a reverse proxy (imho faster) and definitly faster than Varnish under load (190,000+ SSL parallel connections at 4core XEON, 16GB, intel GB NIC - see nginx.org ), can handle more connections and integrates smoothly with Plesk http and https, while using less memory. Also nginx performance can be further increased with a redis-based cache, which actually makes nginx much more efficient and faster than Varnish.

If you are not that apt with nginx and look for Microcaching, you should just go for the Onyx Beta (17.8.9 or something).

Just from my perspective:
- Plesk web configuration "sucked" in speed and efficiency for a long time, while staying in Plesk vanilla configuration.
- With 17.8.9 Plesk can be configured lightning fast out of the box. In fact you are able to build the fastest possible hosting environment this way, able to hold a large amount of parallel connections.
- Adding Varnish only increases complexity, memory consumption, CPU consumption, slows down the site configuration and adds security holes.

So considering the last point, my question: why would you add Varnish? Or is there a specific need you didnt mention?
A bit more information about this would be useful?

I've used varnish in alot of scenarios as and don't have much experience in NGINX. It looks like its possible that NGINX is/can be faster but varnish can be configured to suit any coded setup (i.e. don't cache by Cookie etc etc etc / Not sure if this is possible in NGINX), but doesn't appear to be as malleable as varnish, and would depend on your requirements.
A Guide to Caching with NGINX and NGINX Plus - NGINX

Microcaching looks Ok, though I would suppose that would work for a single website under hi-load (or sites) as its clearly cache in very quick intervals, rather than a Shared Tenancy Server serving lots of sites across many domains with a less persistent load distribution (i.e. 1000 users / 10 sites in 1 minute) rather than 1000 users on one site for 1 minute.
Not saying Im right here, but I don't think they are an exact match of technology and to me, provided the cost of Memory and CPU isn't high varnish looks like a better (easier) option at least at this stage.

Probably worth looking at this, [O’Reilly Ebook] Complete NGINX Cookbook: Your guide to everything NGINX

These are assumptions only, but I have non-plesked Windows backends which In theory I suppose I can forward a request to the Windows Machine and use the Plesk install (Linux) to run the SSL termination via NGINX. I don't think that alone is worth adding in Varnish, I do like obfuscating the Windows server though. If this is possible then it could remove the need for a proxy saving us a monthly fee.
In terms of performance, there are alot of suggestions varnish will speeds things up, but that may be more particular to WordPress - Which could be reason enough to use Varnish.

Not saying NGINX is not the best choice depending on your requirements, but varnish and VCL are easy to use from what I've seen, if the benefits outweigh the costs go for it.
Will keep reading up on NGINX, and see if I can figure see that all items can be matched
A Guide to Caching with NGINX and NGINX Plus - NGINX

It does look to me like varnish may suit a large tenancy better at least at this stage of my understanding of NGINX
9 Tips to Improve WordPress Performance with NGINX
for example - this sort of customization would not be needed, x300 sites? seems like alot of work, but for one site is very easy. Also depends on what the system will do for you
server {
server_name example.com www.example.com;

root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;

include /path/to/wordpress/installation/nginx.conf;

location / {
try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}
 
Back
Top