You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're running a WordPress + WooCommerce multisite setup with 20+ subsites behind 9 Varnish servers. After installing and configuring the vcaching plugin, we're getting 502 and 503 backend errors on multiple actions, including importing WooCommerce CSVs, editing nav menus, updating pages, and using the theme customizer.
I checked our server logs and see what's happening is that, on saving / submitting changes, vcaching is requesting purges for nearly all our content, including homepages, feeds, and blog posts. Because we have so many sites in our multisite network and so multiple Varnish servers, the purge requests don't finish before our PHP execution limit of 120 seconds is reached, thus causing the 502 and 503 backend errors. Importantly, the changes we submit are actually going through; it's simply that the purges initiated by vcaching don't finish within 120 seconds and the PHP execution is forcefully terminated before completing.
Why does vcaching purge all subsites in a multisite network? Currently if we edit a nav menu in site1, vcaching is initiating purges in site1, site2, site3, site4, etc., which is the biggest factor with the above problem. Shouldn't vcaching limit its purge requests to the subsite that has been updated?
Why does vcaching submit purge requests for severs sequentially? According to our Varnish logs, vcaching requests purges on server1 and waits for them to complete, then it requests purges on server2, then server3, and so on. Wouldn't it make more sense to submit purges to all the Varnish servers concurrently?
Sometimes we remove a Varnish server from our cluster for upgrades or debugging. When we do that, vcaching gets stuck waiting for an OK response from an unreachable IP address. Is it necessary for vcaching to wait for an OK response given that server IPs can and do change semi-regularly?
The text was updated successfully, but these errors were encountered:
We're running a WordPress + WooCommerce multisite setup with 20+ subsites behind 9 Varnish servers. After installing and configuring the vcaching plugin, we're getting 502 and 503 backend errors on multiple actions, including importing WooCommerce CSVs, editing nav menus, updating pages, and using the theme customizer.
I checked our server logs and see what's happening is that, on saving / submitting changes, vcaching is requesting purges for nearly all our content, including homepages, feeds, and blog posts. Because we have so many sites in our multisite network and so multiple Varnish servers, the purge requests don't finish before our PHP execution limit of 120 seconds is reached, thus causing the 502 and 503 backend errors. Importantly, the changes we submit are actually going through; it's simply that the purges initiated by vcaching don't finish within 120 seconds and the PHP execution is forcefully terminated before completing.
Why does vcaching purge all subsites in a multisite network? Currently if we edit a nav menu in site1, vcaching is initiating purges in site1, site2, site3, site4, etc., which is the biggest factor with the above problem. Shouldn't vcaching limit its purge requests to the subsite that has been updated?
Why does vcaching submit purge requests for severs sequentially? According to our Varnish logs, vcaching requests purges on server1 and waits for them to complete, then it requests purges on server2, then server3, and so on. Wouldn't it make more sense to submit purges to all the Varnish servers concurrently?
Sometimes we remove a Varnish server from our cluster for upgrades or debugging. When we do that, vcaching gets stuck waiting for an OK response from an unreachable IP address. Is it necessary for vcaching to wait for an OK response given that server IPs can and do change semi-regularly?
The text was updated successfully, but these errors were encountered: