Question

I have Apache setup with Plone 4.2 and SSL with the following rules in the ssl.conf Apache file:

RewriteEngine On
ProxyVia On
Redirect permanent / https://mywebsite.com/PloneSite/subfolder
RewriteRule ^/(.*) http://localhost:8080/VirtualHostBase/https/%{SERVER_NAME}:443/VirtualHostRoot/PloneSite/subfolder/$1 [L,P]

However, about once-twice a day (seemingly at random), the site will get really slow and eventually start serving up 502 errors (Proxy Error). The only thing that appears to fix it is to restart plone with “plonectl restart”. I’m really at loss as to what is causing this, are there any of the rules above that appear to be incorrect?

Answer 1

This is not a proxy setup problem; Apache proxy rules for Plone either work or they don’t. The proxy error is caused by Plone no longer responding, and that is why restarting Plone fixes the problem temporarily.

You’ll need to figure out why Plone stops responding. This can have any number of reasons, and you’ll have to pinpoint what is going on.

• You could have a programming error, one that ties up a thread forever, in part of your site. Once you run out of threads, Plone can no longer serve normal requests and you get your proxy errors. You could use Products.signalstack to peak at what your threads are up to when your site is no longer responding.

• It could be something trashed your ZODB cache; if a web crawler tried to load all of your site in short succession, for example, it may have caused so much cache churn that it takes a while to rebuild your catalog cache. Take a close look at your log files (both from Apache and the Plone instance) and look for patterns.

  In such cases you’d either have to block the crawler, or install better caching to lighten the load on your Plone server (Varnish does a great job of such caching setups, with some careful tuning).

• Some inexperienced catalog usage could have trashed your ZODB cache, with the same results. In one (very bad) case that I’ve seen, some code would look up all objects of a certain type from the catalog, call getObject() on those results (loading each and every object into memory), then filter the huge set down to a handful of objects that would actually be needed. Instead, the catalog should have been used to narrow the list of objects to load significantly before loading the objects themselves.

• It could be you are not taking advantage of ZODB Blobs; large files stored on and served directly from the disk instead of from ZODB objects spares your memory cache significantly.

All in all this could be some work to sort out, depending on what the root cause is.