The Murmatrons

Updated to sync with WP-Super Cache 0.6.6

I just noticed that some people have actually subscribed to these comments.

Lots of changes and fixes. (although I guess that depends on how long ago you were here).

Released version 0.5.55.555

Storage backend selection in WP Admin UI finally implemented.

More changes than you can shake a stick at.

Changelog

Hi Lazy,

If you’re referring to the APC-Cache stats on the Plugin admin page, then you probably won’t see any Hits if it’s just you browsing. You’ll see the 304s (sent Not Modified response) number go up instead. This is better than a hit since no content is sent, just the header.

The stats shown on the admin page are incomplete for APC at the moment – for example, the number of cached pages, expired pages etc. doesn’t work yet. APC has it’s own built in stats which I need to work out how to use. :)

If you mean that APC’s built in stats (apc.php) aren’t showing any hits then that’s bad and I’m not sure what the problem is – I’ve been using eAccelerator for years and only installed APC last night to develop the plugin backend. It definitely works for me, without even configuring any of APC’s settings.

Also; this plugin should work just fine with the APC Object-Cache active at the same time. They do different things, although APC memory usage could be an issue.

In a determined effort not to reach version 0.6, I have released Version 0.5.9.5

Dave,

That’s strange. It activates and deactivates just fine here. I always test that very thing before release just in case I’ve broken something.

What version of PHP are you using? That error sounds suspisciously like PHP4 trying to do something that requires PHP5. I thought that I’d been pretty careful in that respect but maybe something that I’ve done doesn’t work with older versions of PHP.

Ahh, I didn’t realise PHP5 was required.

Neither did I :( It wasn’t intentional, so I guess I’ll have to set up a PHP4 server and in the mean time put a PHP5 required warning next to the download.

Released Version 0.6

Hopefully this release removes the requirement for PHP5. PHP4 should be OK now, but is currently untested beyond a php -l syntax check (with v4.4.8).

Now includes more speed (as the somewhat ironic result of removing all the static class members) and new (optional, off by default) debug logging.

Released Version 0.6.5

New improved SuperCache expiry method.

Finally; a use for all those .postid files that have been floating around.

Shami,

I’m not sure what is going on there. The plugin just checks if the eaccelerator_put function can be used in PHP. If it can, it means that the eAccelerator API is available and the eAccelerator option will be in the list.

The eAccelerator trouble shooting page does say this…

eAccelerator has been reported to work with Zend Optimizer’s loader. Zend Optimizer must be installed after eAccelerator in php.ini so it’s loaded after eAccelerator. If you don’t use scripts encoded with Zend Encoder then we do not recommend installing Zend Optimizer with eAccelerator, and it won’t give you any extra performance.

Maybe the problem is Zend Optimizer.

Your eAccelerator settings look OK to me, but that doesn’t mean it’s working properly.

There is no conflict between WP-SuperCache-Plus and the Object-Cache.

It’s late here now, but I’ll try to devise a test tomorrow that might help to find the problem.

I’ve spent some time looking at this problem and have come to the conclusion that the only way that eAccelerator will not be included in the list is if it isn’t working properly. There are myriad reasons why any of those PHP caches don’t or won’t work on any particular server and I’m afraid that I can’t really help out with that.

I’ll also take this opportunity to recommend not installing eAccelerator, APC or anything else just to use this plugin. You’re multiplying your chances of failure. WP-SuperCache-Plus works without them and the extra functionality of the pluggable storage backends is really aimed at those who are already using those caching systems.

All I can say for certain is that if it’s installed and configured correctly, then the plugin will give you the option of using it.

WP-SuperCache-Plus will support memcached. It’s one of the things that I’m working on, but I’ve also been very good at finding reasons to avoid it since memcached is a bit more complicated than the others.

I’ll probably do it after the next release which, for those who are interested, may well include support for purging frontend reverse proxy caches like Squid, Varnish etc. when posts are edited, deleted and suchlike.

I have a roadmap. Unfortunately, it’s covered in multiple pile-ups.

Released Version 0.6.6

Added support for purging frontend caches – Squid, Varnish etc.

Released Version 0.6.6.6

Finished APC storage backend – it now has the same capabilities as Disk & eAccelerator.

Moving on to do memcached which will probably take a while.

Released Version 0.6.7

Fixed (rare) possibilty of residual tmp files in SuperCache directory.

Gene,

You’re the second report of this and I’ve been thinking about probable causes again and have to revise my assertion from my earlier discussion with Shami.

The most likely cause is that eAccelerator has been built (deliberately or by accident – I know not which) without the --with-eaccelerator-shared-memory compile option.

According to the Compile Configuration page, that option was on by default up until v0.9.5 which implies that it’s disabled by default in newer releases.

The plugin tests for the eaccelerator_put function which is not available without this compile option; thus you see all the benefits of eAccelerator working, but the plugin can’t use the missing bit.

As for WordPress version – I develop and run it on both the svn trunk and 2.6.3, so yes it works on 2.7

ovidiu,

This plugin is based on WP-SuperCache 0.6.something. Most of the major issues found with that plugin have been included in this although they haven’t necessarily been addressed in the same way.

There’s some divergence, some extra functionality, some things have been removed and some things have stayed the same.

The lastest release was the day before yesterday, so it’s about as up-to-date as I can manage.

I’m somewhat at a loss here as to why you aren’t getting the eAccelerator option in the list.

It literally comes down to this single line of code at the beginning of storage/eaccelerator.php…

$_WPSCP_storage_available = function_exists('eaccelerator_put');

I considered it pretty emphatic – the function either exists or it doesn’t, but perhaps on certain platforms, configurations or with certain PHP extensions, function_exists is unreliable.

Edit: Forcing one of the storage engines to work by overriding the availability test probably isn’t a good idea. Fatal errors are what you’ll get. I’m leaving it in for the sake of continuity of discussion.

You could try changing that line to…

$_WPSCP_storage_available = true;

…and see if anything useful happens beyond getting the option in the list and warnings in your logs.

I really don’t know if Nginx is a factor or not. I’m assuming that PHP is done using some kind of fast-cgi setup with Nginx. Surely PHP extensions work just as well in that environment as in Apache mod_php. It wouldn’t have gained as much traction as a platform if they didn’t.

With respect to the Neosmart object-caches, I’ve already done an updated eAccelerator one here that implements some extra stuff that’s important in newer versions of WordPress. I don’t use it though since on this server it doubles page generation time.

Any incarnation of object-cache.php is compatible with my SuperCache plugin since they do different things entirely. The eAccelerator object-cache does require a functional eaccelerator_put though :(

Just for the record, this server is running the latest version of the WP-SuperCache-Plus on:

• Windows 2000
• Apache 2.2.9
• PHP 5.2.6
• eAccelerator 0.9.5.3
• WordPress 2.6.3

I’m really keen to get to the bottom of this but with so many variables it’s not easy.

It needs another way to know eAccelerator is present and accounted for.

There isn’t one. A Fatal Error calling an eAccelerator API function means that for the purpose at hand that function is not present and accounted for. It seems that the function_exists result was telling the truth. The function isn’t callable, but why is another matter. It isn’t a failure in my plugin in so far as I can only work with what’s available.

The Disk problem seems likely to be the result of the plugin failing (due to lack of write permissions for server process) to create the directories:

wp-content/cache

wp-content/cache/meta

wp-content/cache/supercache

Creating a wp-content/cache directory that is writeable by the web server and de-re-activating the plugin would be my suggestion.

As an added bonus – I forsee rewrite and other .htaccess related problems on servers other than Apache.

I’ll certainly look into those installation issues in more detail, but I am surprised since those are the areas least changed from the original WPSC. The contents of the config files and .htaccess files are quite different, but the location and mechanism for installing and checking them isn’t – the notable exception being the meta directory which is created and destroyed by the Disk storage engine rather than the main plugin.

As for the non-functional eAccelerator, I can’t do anything other than go by the return value of function_exists('eaccelerator_put'). I’m not arguing that there isn’t something interesting or strange at work there, but it’s clearly outside of the plugin and on the evidence; if the test says it won’t work, it doesn’t.

Due to ongoing strangeness with apparently fully functional eAccelerator installations refusing to offer up the functions necessary for key caching, I’ve created a small test file – copy, pasta, save-as, whatever test.php somewhere on your server etc. etc. – that will show the availability of functions required for WP-SuperCache-Plus to work with storage engines other than Disk.

It currently only works for eAccelerator and APC because I can’t find any documentation on what extension name to look for with Zend-Cache and I’m not up for guessing. Nobody uses it anyway, so who cares.

Note that this is how PHP sees the extensions and if the necessary functions aren’t present then there’s naught that I can do.

Here’s the aforementioned php file in phps format

The output will look something like this example on my server. which should show (assuming that I haven’t changed anything since I wrote this) an eAccelerator API of 25 functions – 4 of which are necessary for the plugin to use it for storage.

Note: This has nothing to do with whether the plugin as a whole will work or not – Disk storage is always available. It’s only about whether the APC or eAccelerator storage will be usable.

OK, I’ve trawled though the eAccelerator source code and the difference between the functions I have available from eAccelerator and what you guys have posted corresponds exactly to eAccelerator being built without the following disabled-by-default options…

--with-eaccelerator-shared-memory (required by plugin)
--with-eaccelerator-sessions 
--with-eaccelerator-content-caching

I’m thinking that this is not a coincidence.

As for the ‘Not Implemented’ stats; The Disk based storage doesn’t keep track of those stats since it would require a file open, file read, file write operation for every single page view. I was of the opinion that this constituted an unacceptable amount of entirely avoidable disk activity. As I understand it, one of the reasons that the file based object-cache was dropped out of WordPress a while back was that the amount of disk activity generated was really pissing off some hosting companies, so I’ve always paid heed to minimising avoidable disk activity when developing this plugin – thus; no stats for disk.

Implementing the (work-in-progress) memcached storage means I’m going to have to add the facilty for a storage engine to have its own settings section on the admin-page, so the stats for disk thing could become a switchable option at some point in the future.

Excellent – I’m glad that you got it working and I don’t have to go insane :\

Keep an eye on memory usage so that the cached keys don’t cause compiled scripts to be forced out of memory.

I’m going to add a note about the compile options to the article.

Released Version 0.6.8

Minor changes and fixes.

I’ve removed the pluggable wp_redirect function from wp-cache-base.php

When I was working on handling internal WordPress redirects, I thought that I would need to modify that function, but in the end I didn’t.

Since that function was overriding WordPress’ wp_redirect with an identical copy, the headers already sent Warning on user delete may just just move there.

Anyway, I’ve released Version 0.6.8.5

Released Version 0.6.9

Requests that generate a SuperCache entry (anonymous users) no longer also generate an identical WP-Cache entry that will never be used for anything other than wasting shared memory or disk space.

ovidiu

I honestly don’t know. I’ve never tried MU (I suppose I should).

It is possible that I’ve changed something that might be a problem on MU, but I think that if anything it would be something file path related (maybe includes not working) rather than the actual cache functionality.

There’s nothing that I’ve done on purpose that should make those instructions invalid.

I’m going away for the weekend now, but I’m adding MU to the list of things I need to test – unless you want to test it first ;)

Released Version 0.7

Added XCache storage.

Released Version 0.7.1

Fixed a problem with‘Directly Cached Files’.

Added XCache checking and actual PUT/GET/DELETE test to test.php.

EDIT: Nooooooo!!1! This is wrong. I spoke too soon – I need to look at this in more detail. Removing the define from the config file causes problems.

Ovidiu,

Thanks for that – I haven’t had time to look at WPMU yet.

On the basis of what you posted, there’s one very obvious thing that isn’t MU compatible…

I’ve hard-coded /plugins/... in the define near the bottom of .../wp-content/wpscplus-config.php (and wpscplus-config-sample.php).

define('WPSCP_HOME_DIR', WP_CONTENT_DIR.'/plugins/wp-supercache-plus/' );

Having that define in the config file is one difference between this and Donncha’s SuperCache and without trawling my SVN logs I’ve no recollection of when and why I put it in there.

I’ve just tested with that line removed and everything seems to activate and function just fine. Without it, the value of that constant is assigned differently and should be WPMU compatible.

That line in the config file is at least part of the problem and needs to go.

EDIT2: Now I remember why I did that – dirname(__FILE__) in ...wp-content/advanced-cache.php returns the wp-content directory rather than the plugin’s installed directory on Windows servers because advanced-cache.php is not a symlink.

Changing it should be fine.

Removing it should be fine on a Unix/Linux box, but it screws up horribly on Windows servers (like mine).

This problem has its origins in the fact that advanced-cache.php is probably a symlink under Unix/Linux and definitely isn’t a symlink under Windows.

I’m pondering on the best way to sort this issue once and for all – what seems to be the most sensible is to make advanced-cache.php a real file (on all platforms) that does nothing but include the phase1 file. That does away with the maybe it’s a symlink, maybe it’s not problem.

That’s how I’ve always set up SuperCache on Windows servers anyway.

The next release will have this sorted.

Released Version 0.7.2

Fixed a problem with the WPSCP_HOME_DIR define that didn’t work with WPMU.

ovidiu,

I installed ‘Who Sees Ads’ and messed around with combinations of settings, but I can’t replicate that.

What’s in your SuperCache ‘Rejected URIs’ box?

Can you try suppressing the warning by changing line 168…

if( preg_match(...

… in wp-cache-phase2.php to …

if( @preg_match(...

… and see if the Headers Already Sent warnings are still there.

If you escape those question marks there will be no problem.

\?action=
\?topic=

Now that’s really weird – I can escape them no problems.

I just type my comments as valid XHTML 1.0 Strict so I don’t have to guess what WordPress will make it look like – It’s a bad habit that I’ve picked up over the years :-) and I can’t rightly claim in the footer that the page validates and set about breaking it deliberately.

The biggest difference between what I do and what WordPress converts your comments to anyway is that I use the <pre lang="whatever"> (WP-Syntax plugin) and <tt> tags a lot.

e.g.

<pre lang="text">\?action=
\?topic=</pre> gives you

\?action=
\?topic=

To be honest, I can follow your comments just fine. There was an issue until a couple of days ago where I had the WordPress automatic comment formatting disabled. Unfortunately, now that I’ve turned it back on this page no longer validates and all the errors are caused by WordPress ‘fixing’ the comments. I think that WP 2.7 is better in that respect, but this site is still 2.6.5

Released Version 0.7.3

Fixed a problem where using the No-Cache for Registered Users plugin would prevent SuperCache expiry.

The .htaccess rules haven’t changed in ages and I don’t think that anything that I have planned will require any changes.

I’d certainly flag it up if they did need changing.

Released Version 0.7.4

Added Memcached storage engine.

Released Version 0.7.5

Added Memcached-Alt (alternative cache purge method) storage engine.

Bumped 0.7.5 up to Version 0.7.5.1

Improved Memcached-Alt cache flushing.

Prasannah,

It’s good to know that it worked on PHP4 – that’s something that I was never 100% sure of. There should be no problems with PHP5.

I looks fine to me – I can see the footer although there are some pages coming from the SuperCache that don’t have it.

Switching the footer message on/off doesn’t clear the cache, so the change won’t appear on pages that are already cached until they have expired (or until you delete the cache).

The easiest way to see if everything is working as expected is to look at the response headers that come with the page using something like Firebug. The plugin inserts X-WPSCP headers that tell you where the page is coming from – Dynamic, Cache or SuperCache.

ovidiu,

Thanks for that – downloaded and I’ll take a look. I’m off to visit family for a few days so I’ll need something to keep me sane :\

My first thought from reading about it is that while caching queries may be very nice, a significant (sometimes huge) proportion of the render time on many blogs is spent in plugins doing preg_replace or similar on the content and/or comments. – Query caching won’t do much for that.

This post is a good example – It runs 32 queries like pretty much every other post does, but takes 5 times longer to render than most of them because of the large number (for this site) of comments.

Having said that, I haven’t looked at it yet so I’ll reserve judgement.

The widget-cache is based on exactly the same reasoning that I’m following…

Caching at the highest possible level gives the biggest benefits and caching the hierarchy of components that got you there minimizes the amount of work that needs to be done when something changes.

Widgets, just like plugins, can have a huge effect on page generation time – many use a remote API that makes your site’s load time dependent on someone elses servers, some are quite complicated, while others are just horribly coded. You might even get lucky and find some that are all of those. Caching the output of the little fuckers is definitely the best thing next to not using them.

My only beef with it is that it caches to disk. I’d rewrite it before using it.

As far as following or forking goes, I’m just doin’ my own thing but if I see any good ideas from anywhere that makes it better I’ll give it a go. I’ve tried to keep compatibility, but really only in terms of the plugins and hooks.

Once I’ve finished the the page fragment caching that I’m working on now, I want to try and remove the whole Apache-centric thing and support other servers better – nginx being top of my list. Beyond that I have no idea where I’m going with it.

just noticed donncha updated to 0.9 which proimises to halve the number of cached pages

Based on a quick skim over the code in trunk, I think I fixed that one a couple of months ago.

Released Version 0.7.5.2

This should fix the headers already sent warning.

The output buffer ‘fix’ for PHP-Speedy seems to be a non-starter. I’ll need to look more closely at how to fix it properly.

Retracted

My new theory is that it’s a plugin doing it.

Try commenting out the flush(); at wp-cache-phase2.php line 675

Yes, I get the same error with IE and see the warning, but I’m not 100% convinced that the two problems are related.

The IE error looks like what you get if the content is gzipped twice. Since the problem is when you F5 and get the SuperCached static file, it suggests to me that mod_deflate is gzipping the SuperCache .gz files. If you have mod_deflate active, try turning off the SuperCache compression option to see what happens. If that fixes the IE problem, check that the .htaccess in the wp-content/cache directory has the following in it…

<IfModule mod_mime.c>
  AddEncoding gzip .gz
  AddType text/html .gz
</IfModule>
<IfModule mod_deflate.c>
  SetEnvIfNoCase Request_URI \.gz$ no-gzip
</IfModule>

That’s supposed to prevent mod_deflate from gzipping the already gzipped files.

The warning disappears when you F5 because it doesn’t get cached – it’s happening after SuperCache’s shutdown callback. That’s what makes me think that some plugin has registered a shutdown callback and for some reason is trying to send headers after the content has already gone.

Can you search the .php files your plugins directory for the string shutdown

Are cache misses supposed to be that high, at least at first? Seems odd that with over 182 cache files generated, it would only hit on 3 of them.

At the risk of being patronising, I’ll start by pointing out that there are two caches. Cache and SuperCache. Maybe you know that, maybe not. No offense intended.

Misses will often be high at first since each new page being cached is a Miss.

The 182 static Super-Cache files (that’s files, not pages) are being generated by anonymous (no cookies set / not logged-in) requests and are only served to anonymous users. They don’t figure in the Hits, Misses & 304 statistics. Those stats only apply to cookied / logged-in requests.

With Super-Cache enabled, I’d expect to see 304s being higher than Hits.

With Super-Cache disabled (Half-On mode) everything goes into the same Cache so now the Hits/304 ratio will depend on the ratio of registered/anonymous.

Also – keep an eye on eAccelerator memory usage as you don’t get any warnings when it fills up.

I’ve looked at the list of plugins and there isn’t much to go on.

I’m a bit lost on this one – There’s a <br /> tag at the end of your html after the </html> tag whenever the warning is visible, so something is definitely sending content after SuperCache has got everything and cached it.

Here’s a replacement wp-cache-phase2.php that will log what’s going on with the output buffers to wp-content/wpscp-debug.log. I’m hoping that it might reveal an output buffer above SuperCache and give us a callback function name that we can track down. If not, I’ll have to put my thinking hat on again.

The output will look something like..

2009-02-03 10:13:41 T+2110 - Buffer flushed: wpscp_ob_callback
2009-02-03 10:13:41 T+2112 - Buffer remaining: default output handler

Fingers crossed :\

Fuck! Now that’s a mystery.

If it weren’t for the weird IE error which may be related, I’d say “fuck it” and just set

display_errors = Off

in php.ini and forget about it.

Donncha has been having some interesting shutdown/buffer related fun lately in this WP forums topic and has shuffled some stuff around to try and solve it. I’m about to take a look at what he’s done.

But first, here’s a zip with a new phase1 & phase2 for you to try where I’ve shifted the start of output buffering as early as is possible in the process. Let’s see what happens with that.

wp-supercache-plus_obstart_test.zip

It’s a bummer – if this crap was happening on my own server I could probably track it down very quickly.

Out of curiousity; have you tried Donncha’s SuperCache to see if it does the same thing?

I’d recommend going with whatever works.

I’m in the middle of a major rewrite of the supercache garbage collection and purging at the moment and it’s probably going to be a few weeks before that’s ready for release.

What Donncha did a few days ago seems to make sense and it’s quite possible that it’s what’s making the difference on your site. I have a couple of reservations about it though and want to test some variations before I jump in and implement the same thing in mine.

In a way, that’s good – It isn’t just Ovidiu that has the problem. There’s something going on that needs fixing.

Unfortunately, I’m not sure what it is. I’ve already (in my dev version) moved the start of output buffering much earlier, but I don’t get that error so I don’t know if it will do any good.

What gets screwed up in the feeds? This plugin caches the feeds whereas (I think) the original doesn’t. My feeds work fine cached but I guess it may make sense to make it a switchable option.

I’m hooking wp_redirect so that I can detect redirects and avoid caching them.

I’m not changing anything on purpose, but it could well be because I’ve left out a return in the callback.

Try adding …

	return $status;

at the end of the wpscp_redirect_callback function @ line 836 of wp-cache-phase2.php

That’s the only interaction with redirects in the plugin – detect and ignore.

Hope that sorts it.

With a single server, caching to memcached will probably be slower than caching to eAccelerator due to the protocol overhead. Memcache can however use multiple servers and allow for multiple web-servers sharing the cache. eAccelerator can’t really do this, so for huge sites memcache is much better.

If you’re referring to Ryan Boren’s memcached object-cache for WordPress not working on multiple blogs, I suspect that it may not be written to support that scenario. All the storage engines in my SuperCache plugin support multiple domains on the same server, as does my eAccelerator object-cache.

There’s nothing to stop you using eAccelerator (or some other op-code cache) and memcache at the same time. eAccelerator stores the compiled scripts making the scripts run faster and memcache is used for caching content.

It does seem like your eAccelerator is not loaded at all. That test is just reporting back what PHP knows about the extension.

Interesting.

The test.php came about because some people were having problems with eAccelerator being loaded and apparently functional, but not available as an option in SuperCache-Plus.

If it’s available in the drop-down then it will probably work – don’t worry what test.php says. I’m not really sure what’s going on with that but I’ll have a look-see and try to figure it out.

I doubt that the web server process could write to /root/tmp and I doubt that making it so it can would be a wise thing to do.

Is there a quota in place on /tmp that could be increased?

I’m somewhat reluctant to make judgement calls on how anyone’s server is or should be configured – it’s over 2 years since I quit my job as a sysadmin and have hardly touched a lunix machine since then, so I’ve forgotten more than I care to remember. I don’t want to give any bad advice.

Personally, I have eAccelerator configured to never lay down disk files ( eaccelerator.shm_only ), but in that case you absolutely need to have enough RAM allocated to it to make sure it never overflows otherwise the whole thing is pointless.

I’m guessing the gallery creates files in /tmp when creating thumbnails so when there’s no room it fails.

Having no idea how much space is available in /tmp, what it’s full of or why it’s limited to to what it is, I can only suggest looking at ways to either clear it out with a cron job or not fill it up in the first place.

Guy,

Firstly, congratulations on having the sense of adventure to try the SVN version.

On its own, that Division by zero warning isn’t really anything to be concerned about. It’s where the plugin attempts to calculate the cache request rate when the cache hasn’t actually been used yet (it has just been created or cleared). It’s something that will be cleaned up before the next main release, but has no effect on functionality at all.

If, however, you’re getting that warning repeated on every request and the Stats in the Cache Contents section of the plugin admin page never get away from zero, then something isn’t right.

Are you getting any meaningful cache stats on the admin page?

I can’t really comment much on what XCache settings are best or which won’t work. I test the plugin using XCache’s default settings (on a Windows server) and it works, but I don’t actually use XCache on any production servers so I’ve never really had any compelling reason to play with the settings.

That’s something I didn’t even notice. Or perhaps I did, at the time, and then forgot about it.

xcache_list is an admin function and requires the php.ini setting xcache.admin.enable_auth = Off. That setting would be a bad idea on shared hosting but isn’t a problem on a private server (virtual or otherwise).

For now that’s the solution and it appears to be a requirement for some other cache projects that use XCache. I’ll look into it in more detail.

I looked at your phpinfo and don’t see any evidence of eAccelerator being loaded.

Yours:

Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

Mine:

Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

It’s certainly documented that eAccelerator must be loaded before Zend Optimizer in php.ini but using them together is not recommended.

Perhaps that’s the problem.

From your phpinfo it seems that the site is running as FastCGI on a Dreamhost shared server. I’m a little sceptical as to whether eAccelerator can be used effectively there (if at all). It needs a bare minimum of 32M of memory allocated to be useful for this plugin. Much more is better.

If you are indeed on shared hosting, I would recommend against trying to use eAccelerator storage with this plugin. If you hit a server memory cap, your site could get shut down.

I don’t know of any reason why it wouldn’t work with PHP Speedy, but I haven’t tested it myself.

I did implement a variation on a fix for the regular SuperCache plugin suggested by someone on the WP support forums who was having a problem with them working together. It was quite a while ago and just a matter of handling output buffering a bit better.

The 500 errors could be due to XCache itself. I’ve seen the occasional random errors (not lack of memory related) with both APC and XCache on my server, but never with eAccelerator.

Guy,

I think the memory usage for the ‘Super’ part would be mostly due to the garbage collection. The generation and serving of the static files really shouldn’t use much at all.

The version that I’m working on should use much less memory for garbage collection since it does away with the need for recursive directory scanning.

Vito,

10 requests per second with ab in half-on mode doesn’t sound good. You shouldn’t be seeing 99% cache misses either. If the cache is primed, you should see 100% hits in half-on mode.

I’d expect to see hundreds or thousands of requests per second depending on the hardware. My super-slow test server (a 600MHz P-III) does about 85 per second.

Try benching half-on with disk storage. Perhaps eAccelerator isn’t storing the pages at all. You could also try benching an article page rather than the root of the site in case something about your site setup is preventing the ‘home’ page from being cached.

I’ll try to have a look at PHP Speedy when I’ve got the latest iteration of the plugin cleaned up.

Vito,

Can you clear the cache and change the define('WPSCP_DEBUG', false); to define('WPSCP_DEBUG', true); in wp-content/wpscplus-config.php and do an apache bench with a small number of requests – maybe three would do so I can see page generation and (supposedly) cached responses – and then copypasta the contents of wp-content/wpscp-debug.log here.

The most likely cause of the 500 - Unexpected zero-length content is hitting PHP’s memory limit, but it’s almost impossible to know exactly what’s going on without stepping through the page generation with a debugger.

Have you checked for anything interesting in your server error log that would relate to either problem?

Ovidiu,

It should be easy enough to detect suPHP and restrict the plugin.

Vito,

Thanks for the debug logs. The SuperCache is clearly not working –
either the .html files aren’t getting written to wp-content/cache/supercache/domain/.. or the Apache rewrite rules are wrong/missing. The rewrite rules from the regular WP-SuperCache aren’t still in the /.htaccess by any chance?

According to the logs, Half-On seems to be working just fine for both disk and eAcc. The cached pages are being served in around 1ms. I can’t understand why that doesn’t benchmark as being really fast. :(

Edit: I just had a thought that might account for some of the discrepancy – I notice that the plugin isn’t doing gzip. Is mod_deflate perhaps gzipping the content on the way out? I can’t believe it would be that slow, but I’m clutching at straws.

XCache is odd. Most of the caching systems that I’ve seen using XCache seem to require

xcache.admin.enable_auth = Off

due to several useful functions being ‘admin functions’.

Whether that’s wise depends on whether someone else can create an admin page on your server.

I’ve rummaged through the XCache source code again and I still can’t see a way around it. It would be nice if the admin functions took username/password as arguments, but they don’t.

Why it doesn’t accept the username and password is a mystery. The source code implies that it should, but it doesn’t work for me either. Even if that did work, cache purging actions triggered by users (e.g. commenting) would still fail since they don’t know the username and password.

Also; XCache documentation sucks. I just thought I’d get that off my chest.

Not tested with 2.8 yet, but I’m not aware of any reason why it won’t work.

Tested with WP2.8

Nothing exciting to report. Everything seems boringly normal with respect to normal operational parameters.

I also publicly resolve to find more time to get back to developing this plugin in the not too distant future. I did fix a bug in the bleeding edge SVN version today, which at least means I still remember how it works.

James,

I don’t use XCache on any production servers, but here’s the php.ini settings that I use on my dev (Windows) server. It works for me (or I would have given up trying to support it in the plugin).

[xcache-common]
zend_extension_ts="php_xcache.dll"
 
[xcache.admin]
xcache.admin.enable_auth = Off
xcache.admin.user = "admin"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = ""
 
[xcache]
xcache.shm_scheme = "mmap"
xcache.size = 16M
 
xcache.count = 1
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 3600
 
; same as aboves but for variable cache
xcache.var_size = 8M
xcache.var_count = 1
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
 
xcache.test = Off
xcache.readonly_protection = Off
xcache.mmap_path = anonymous
 
xcache.coredump_directory = ""
 
xcache.cacher = On
xcache.stat = On
xcache.optimizer = On
 
[xcache.coverager]
xcache.coverager = Off
xcache.coveragedump_directory = ""

Everton,

It’s hard to say. I’ve seen all kinds of feedback on DBCache and it seems to me that what you get really depends on the individual site and its traffic patterns. I tried it and found it made things slower, but then I don’t use any plugins that hammer the database and I’m using the (not finished yet) fragment caching functionality of my plugin which tends to reduce the DB load anyway.

I’d try with and without and see which works best for your site(s) – there’s no incompatibility issues that I’m aware of.

decided APC was better anyway

I’d tend to agree with you there, but I shy away from recommending or slighting any particular option since it’s impossible to know the degree of pseudo-religious devotion that someone might have.

The last thing I want is an X is better than Y flame war :\

I just try to make each option work as well as it’s functionality and API will allow and leave it up to the user to find the right one for them.

Everton,

The php.ini setting you changed for Super-cache isn’t the cause of the problem – it just prevents APC from caching the Super-cache config file so that when you change settings they take effect immediately. In fact; I suggest that this might be a good idea for my plugin in the APC notes of the readme. eAccelerator has a similar feature and similar solution.

Unfortunately, the warning message from your logs isn’t very helpful. Without something like XDebug that logs a trace for the warning, it’s impossible to tell where the warning is actually coming from.

I’m loath to suggest turning the plugin’s debug logging on since I don’t think it’s likely to track down the source of the problem.

One suggestion is to run it for a while using ‘Disk’ storage, see if the Warnings persist.

Another is to look at whether APC’s shared memory cache is being maxed out. I don’t know how it behaves when it gets filled up – perhaps that’s where the problem lies. As a rule of thumb (based on my eAccelerator performance) around 16MB is required just for the compiled WordPress scripts. Caching pages in there too means that a relatively small and not particularly popular blog can hit 24MB (total) quite easily.

ANNOUNCEMENT

I’m giving serious consideration to shutting down the comments on this topic and moving over to the Trac I’ve been setting up instead.

A WordPress post and a readme.txt is no longer the best vehicle for the development of this plugin.

The only thing I can suggest is to look closely through the logged Warnings and see if there are others Warnings or Errors mixed in amongst the ‘Cannot Modify Header Information’ ones.

I’m fairly confident that with the way that SuperCache-Plus handles output buffering, any ‘Cannot Modify Header Information’ warning should have a logged error or warning of a different type as its root cause.

You could also copy and paste a representative chunk of the error log to http://apache.pastebin.com/ and then I can have a look myself.

I’m guessing the reason you can’t create wp-content/cache/.htaccess is likely to be the same reason that the plugin can’t create it automatically.

The plugin actually removes and recreates it with new values if you change the Expiry Time in the admin interface to ensure that Apache sends the correct cache-control and expiry headers.

It must be a permissions issue. Apache apparently can’t write to wp-content/cache either.

I don’t think it’s an APC problem, although there is plenty of scope for being wrong there – it’s possible with any PHP op-code cache for problems to arise as a result of the ‘optimization’ they do when compiling scripts. I’m not clear on what optimizations APC does (if any) – the apc.optimization ini setting was removed in version 3, but that doesn’t mean that it isn’t doing it.

I have seen some reports on the WordPress support forums of odd permissions on directories and files supposedly being left as a result of the (possibly failed) WordPress automatic update/upgrade processes.

The fact that you can’t create the .htaccess still makes me point to permissions or ownership issues unless something silly is going on like your ftp client hiding ‘dot’ files from you. That won’t help much though, because if the .htaccess does actually exist but you can’t see it, were still no closer to working out what’s causing all the warnings.

Actually is half-on mode with xcache faster than on mode with xcache?

I suppose it’s possible. Certainly not on my dev hardware – it would max out at around half the requests per second as the static files coming from Apache

My main concern is memory use (I only got around 720MB free for apache to use) and equally important cpu use.

This site is running in 384MB TOTAL with 2 instances of Apache2.2 (one mod_php5 and one mod_php5+mod_python with 64MB allocated for eAccelerator shared memory). I guess it comes down to the size of your site(s) – there’s no way to know how much space the caching is going to use until you do it. Lots of registered users or commenters will require much more cache space than a site that has mostly anonymous hits.

Try starting at 64MB, monitor the XCache usage and increase if necessary.

am I correct in assuming that anyone who put down a comment is considered “registered”?

Effectively; yes. Anyone who has been cookied by WordPress is not served static files.

…still have not really found out how to monitor the xcache usage…

I think that all you need to do is put the contents of the admin directory from the XCache distribution somewhere on your server and http://yourdomain/xcache_admin_directory/

Last things first: I haven’t managed to find a way round the XCache password thing. I don’t believe there is one.

I’m not sure that I understand about the .htaccess and disabled WP-Cache thing. In fact, I’m sure I don’t understand.

You’re likely right about .htaccess being rewritten when it isn’t necessary. Having said that it doesn’t cause me any problems and I don’t have a .htaccess at all, nor can the plugin create one even if it wanted to. Are you seeing logged warnings or just a message about file permissions on the admin page?

To be honest; the code for the admin page is where I’ve done the least work since I forked off of Donncha’s SuperCache. There’s stuff going on in there that is suboptimal for sure. The whole .htaccess / rewrite rules thing is slated for a complete rework anyway to better support servers other than Apache, but it will be a while before I even get started on that.

Yup; It’s a bug that shows if ‘Allow plugins to disable caching’ is set to ‘Allow’.

I’ll fix ASAP, but for the moment just switching that setting to ‘No way’ will stop the warnings. I very much doubt there are any plugin developers that know about that hook, let alone use it.

extremecarver,

I was just thinking about your hits and misses…

Each cookied user gets their own cached copy of each page and each comment would actually register as a cache miss since when the comment is posted the cache entry is purged and a new page is generated to include the new comment, so what you’re seeing there is probably not indicative of anything wrong at all. If most or all of the activity is commenting on one or two recent posts, I think you should expect mostly misses there.

That fact, was one of the prime motivations for me starting the fragment caching functionality in my plugin. There’s usually a lot of stuff on a page that could be reused for a regeneration, but you need some way of saving it first. Only saving fully rendered pages is not the best approach for many usage patterns.

Having digressed momentarily, I’d expect to see cache Hits and 304s much higher in ‘Half-ON’ mode where everyone (including bots) are being served from the same place.

This site is currently currently in Half-ON mode…

Initialised: 2009-07-21 10:28
46 total cached pages (average TTL: 11152s)
39 gzipped pages
36 expired pages
Cache misses: 120 = 52%
Cache hits: 62 = 27%
Cache 304s: 45 = 19%
Request Rate: 222 per day.

Released Version 0.7.5.5

Minor fixes over 0.7.5.1

I’ve moved the location for new versions. This page is in the process of being deprecated.

Running this site in Half-On gives me the best opportunity to catch any problems on that side of the cache in my logs. It doesn’t get enough traffic to merit static files :( anyway and my upstream bandwidth will max out long before the eAccelerator WP-Cache runs out of steam.

Is there actually any possibility to put supercache pages into memory like xcache instead of disk? That would make the site spinning even faster.

That’s the very definition of Half-ON mode. Everything would be in XCache.

As for XCache reinitialising, I don’t know where you’d find anything useful logged if there’s nothing in Apache’s error log.

Strange error. The storage engine template file has indeed been removed from the dev version, although it should never have been selectable.

Edit wp-content/wpscplus-config and find

$_WPSCP_Config->active_storage='Whatever it says now';

Change it to read:

$_WPSCP_Config->active_storage='disk';

That should sort it out.

Update: I’ve just realised what’s happened. The code to hide ‘Template’ from the drop-down list was removed at the same time as the template file. Upgrading to the dev version by unzipping and copying the files has left the template file in place.

I think the plugin doesn’t like being in a directory other than wp-supercache-plus (hyphens, not underscores).

Without trawling through stuff I’ve forgotten about, I’m sure there’s some legacy hard-coding of the directory name.

Deactivation should be enough, but file permissions can get in the way.

If deactivation isn’t enough, manually removing the following should restore WordPress to normal operation:

• The wp-content/advanced-cache.php file.

• The contents of the wp-content/cache directory

For completeness, the rewrite rules should be removed from /.htaccess although if there are no static files to serve they do nothing to interfere with WordPress.

There’s likely to be an issue where if you install one of the dev versions when there are already SuperCached pages. Those files won’t be in the database and won’t get deleted even with the ‘Delete Cache’ button. The plugin doesn’t know anything about them.

This is something that has been bugging me since I suspect that there may be more elaborate ways of creating orphaned files (haven’t found one yet though). Some kind of ’sync db with filesystem’ function is probably on the cards.

As for the wp-cached stuff. I’ve never seen that refuse to cooperate. There’s minimal difference between the release and dev versions there.

Strange, How could I solve it?

Empty the supercache folder?

Yup; cleaning the SuperCache dir should do it.

The dev version tracks SuperCache files in a MySQL table. A record is created before the file is written, so it’s ‘orphan safe’ in so far as if the db insert fails, then no file gets written. Unfortunately it does’t deal well (at all) with files on the disk that don’t have a db record.

All the purging and garbage collection is based entirely on what’s in the database, not what’s on the disk since recursive filesystem traversal was (is) one of the biggest bottle-necks in SuperCache.

I’m forming the opinion that the delete cache button should probably revert to the old ‘kill it with fire’ approach and empty both the filesystem and database. Deactivation of the plugin still does it that way.

I’ve just spent the last while trying to understand that warning.

wpmu 2.7.1 functions.php:2767 uses (if apache_get_modules() doesn’t exist) an output buffer to look at the output of phpinfo() to determine if a particular Apache module is loaded.

There doesn’t seem to be any mechanism by which that function can cause any output.

I even tried putting the following code (does pretty much the same as what seems to be causing your warning) into the very start of my plugin…

ob_start();
phpinfo();
$x=ob_get_clean();
$y=apache_get_modules();

… and that didn’t trigger anything on my server at all.

My gut feeling on this one is that it’s a quirk of a particular PHP Apache SAPI version, but I don’t know.

It might just be a configuration problem.

What IP / Port is memcached running on?

What version of wpscp plugin are you using?