Jawillde

Hopefully the developers will answer this with some sort of option in the next release. I’m close to disabling the plugin due to constant complaints from mobile users about it floating over the page.

I’ve encountered the same problem even using MemcacheD.

Andrew, the issue was with jQuery minification via W3Total Cache. We figured it out after reading a few of the other threads. You may want to put a note or a warning somewhere in the settings because I have a feeling this is going to affect a lot of people.

I see it is working now. We are having a similar issue. What made it work for you?

The last set of updates did not fix the problem.

Its been two updates since I started this thread so when our client that uses this plugin sends their email newsletter out today we are going to activate the plugin and see what happens.

It could just be a bad php script that loops and when web traffic gets to a point where your server has too many of these scripts running endlessly it just eats up your server’s memory and then the CPU can’t function anymore.

Has the development version been updated with this fix?

I’ve experience a similar issue as well and it could be the same memory leak. It may be more related to the more recent version of WordPress as we had no issue until updating.

For reference we utilize MemcacheD between two webservers that are behind a load balancer and utilizing Varnish, but we started getting CPU overload for no apparent reason. Disabling W3 Total Cache fixed the problem.

We then activated the plugin but only one caching mechanism at a time and have found activating Page Cache, Minify, and Database Cache but NOT Opcode Caching works fine. We may disable Database Cache as it looks like it may be a little slower activated in our case.

Just in case anyone is actually following this thread:

The server-side solution is to configure multiple Memcached bins on your Memchached server. Assign a different port number for each bin and set that port on your different domains. This way you don’t need to modify any files if you’re running a MemcacheD server.

Thanks to Rackspace for this solution. Awesome support there.

Hopefully this will help others and maybe Frederick Townes can add the ability to allow user to input a unique prefix in a future update to the plugin.

When running multiple domains through one memcached server you have a cache key problem. Nothing in W3 Total Cache allows you to define the key in anyway. So website xyz.com and abc.com may have cached pages with the same key. One overwrites the other and then both abc.com and xyz.com display abc.com instead of its own respective page. The reason for this is because all the cache keys start with w3tc_ instead of some website specific key and then it is all being served from a memcached server with one hostname. I imagine most use an internal IP for their memcached server since it doesn’t need to be open to the public.

There is probably a server side solution to this, but my hosting company either doesn’t know how to do this or has our memcached server misconfigured. But, either way, I needed a solution now.

My solution (and it may not be perfect or correct but is working so far) is to find all of the cache keys and change the prefix from w3tc_ to something of your choosing. For abc.com you may decide to use abc_ for your prefix. You may also need to disable “Cache requests only for hostname” in page cache options.

The files that I have so far found the cache key prefix in are found in w3-total-cache/lib/W3/

PgCache.php
ObjectCache.php
Db.php
Minify.php

It must be something else. We are using Manual Minify on all our installations.

-James

@Whatsthatbug.com, kathywhatley has your answer. Same thing happened to me. Make sure the plugin is activated after upgrading.

@kathywhatley, we run the Swift theme and have had no issues. You may need to increase the php memory limit in the php.ini file. You’re looking for a line that looks like this:

memory_limit = 8M

Increase it in increments until that ‘Fatal error:’ no longer appears.

Ok, Frederick. This is strange but I’ve figured out where the problem stems from, just not why.

If I check the cache to see if it is working, W3TC is definitely caching the page. I’ve even downloaded one of the cached pages and opened it and it opens correctly in my browser. W3TC “may” not be serving the page from cache but it is still pretty fast so I’m betting that it is.

On General Settings, if you choose to add a link in the blogroll under Support Us, that’s when the problem happens. After deselecting this option and flushing the cache, the stats showed up in the source code.

I deactivated and reactivated, flushed the cache, disabled and re-enabled, and then flushed the cache. Still no change.