| Download: | xcache-plugin.zip |
|---|---|
| Version: | 0.7d |
| Updated: | August 29, 2008 |
| Size: | 0 bytes |
Powered by Drain Hole
This is another one of those articles that will be of interest to a minority of WordPress users. In particular, if you use the XCache PHP opcode cache and Neosmart’s XCache object-cache plugin for WordPress. For those of you who don’t know what the heck I’m babbling about, a PHP opcode cache is a bit of software which helps your web server do less work when turning all your PHP code into web pages that a browser can render. The object-cache plugin is a bit of code added to WordPress which communicates with a caching service in order to reduce the number of database queries it needs to make when building your pages. Together, this helps reduce the CPU load on your web server.
When WordPress 2.5 was released, it introduced some changes to the object cache API. Specifically, it introduced ‘global groups’ and ‘non-persistent groups’, which are just ways for WP to organize and optimize the data it stores in the cache. However, if you didn’t have an updated version of your object-cache.php plugin, you’d start to see some ‘quirks’ in your system. The things I noticed the most were that my comment moderation counts and plugin update counts would not update properly when I flagged comments or upgraded my plugins. I had hoped that Neosmart would update the plugin, but I never saw any news about it, so I ended up just disabling the object-cache on my site.
Then recently, I had to do some work on the memcached version of the object-cache plugin for a client. This inspired me to go ahead and take a look at the code myself, and update the XCache plugin. By looking at the changes to the memcached plugin, I was able to see that it really wasn’t very hard to make similar changes to the XCache plugin.
I’ve sent my changes to the author of the original plugin, but until any official update comes out, you’re welcome to download my changes.
NOTE: this is not a normal WordPress plugin, it does not go in your plugins directory! Install the ‘object-cache.php‘ file directly in your ‘wp-content‘ directory! You must also add the following line to your wp-config.php file, just before the comment that says ‘stop editing’:
define('ENABLE_CACHE', 'yes');This is no longer required in newer versions of WordPress.
For more information, see my previous article, Using the WordPress Object Cache.
UPDATE 2008-09-02: After seeing comments about people getting errors, I took a closer look and found a couple of typos. Version 0.7c should clear those up.
UPDATE 2008-09-11: Updated to version 0.7d, which should do a better job of creating unique keys, even on servers with multiple installations of WP / WPMU. Testers wanted!
I tried your 0.7b version with my WP 2.6.1 installation, and it produces database errors.
The 0.6 seems to work OK, but it stores cached content in the Dashboard, which isn’t good.
Peace,
Gene Steinberg
Hi,
really good idea.. like i posted it on neosmart some months ago the object cache plugins need some rework but they told me they do not.. now i see you are my opinion about that. I tried to migrate your good ideas to the apc cache plugin but i get errors with the wp_cache_add_global_groups and wp_cache_add_non_persistent_groups functions.. missing argument 1..
really good idea
have a nice day
i am looking forward to further improvements 🙂
Chris
Doug, am i getting this right, simply add
define('ENABLE_CACHE', 'yes');under wplang in the config.php file, upload the plugin to the wp-content folder and thats it, it works?yes thats right and all you have to do but i think you should first try 0.6 and then 0.7b from here because (in my opinion) 0.7b seems to have a little bug till now.
Thanks for the comments, folks. I did find a couple of typos, and I’ve updated the code. Try version 0.7c and let me know if it works better for you now.
Thank you very much Dougal 🙂
Pingback: Wordpress APC Object-Cache modifiziert - Projekte, Wordpress
I may just have to re-enable my object cache! I too disabled it due to sticking caches but now that that’s been resolved (too lazy to fix it myself as I’m on an uber server), I may just have to put it back.
Thanks. 🙂
FYI: your download contains your XCache username and password. Might want to remove that. 😉
Also, can you add a var for prefixing all keys? I have multiple things uses my XCache containers and I don’t want any bleed (I assume that’s possible) but more importantly I want to tell the source of the vars. 🙂
I second Viper007Bond, we need to be able to prefix the varnames, because with multiple wordpress installations, the whole “variable cache” thingie goes icki, if you know what i mean..
But thanks. I will have to have a look at the code though..
I’ve just noticed, that there is actually a prefix that is used to build the “key”, but it seems it’s using the global var ‘blog_id’. The previous version did the same thing, but since he md5ed the key, there seemed to be no leakage. The new version saves with a plain text key and that’s why the prefix is important again. I guess we can smiply insert the line
$blog_id=1;
or any other unique number at the beginning of the file to get the object_cache working with multiple blogs.. $blog_id seems to be a wpmu-var, which is read from the database (found on line 119 in wpmu-settings.php).
the same in wp-settings.php from (normal) wordpress. i`ve just changed the blog_id variable in every wp install on my server and it seems to work in my opinion (and i hope, too.. 🙂 )
hope you all have a nice day / night.. 🙂
@Lazy: it seems that’s not the only problem: users, userlogin and other groups are defined as global groups, which means, that they get to be saved ‘globally’ without prefix. For the time being, i’ve switched back to the old version of the object_cache
Viper007Bond: Thanks for the heads-up on the password. I’ve fixed it in the file and changed it on my server.
Hmm, as far as the prefix goes, I think the best solution will be to change the prefix in the key method to be based on the siteurl. It would probably be good to differentiate WPMU from regular WP, and clear the global groups under regular WPMU (and maybe add an optional define for it, as well?)
i see – thank you very much. That could be the Problem or Confusion (through all xcache object-cache versions for wordpress) i`ve got with my blogs if i want to test the 2.x.x trunk of xcache (1.3 is working, indeed) – since my posts in the xcache bulleting board there were no changes in this (2.0-csv + 7 blogs = white/blank pages) problem.. so that i´m with the apc trunk without any problem with any of the versions since i declared the blog_ids to differ. sorry for my english.. since i ve started to learn arabic my english got worse..but in some years i really plan to make something like a wordcamp in syria.. so it`s one of the causes i learn arabic now – and because of all the great people i met there. My girl friend is an arabic teacher at a german school here and she`s crazy `bout syria… so i have to, too.. of course.. women.. 😉
Maybe someday the option to use an op cache will be in the wp core and the user just have to choose.. ok, i`m dreaming – a little bit.. 😉
I`m really interested in your both work(s) and follow them since months 🙂 have a nice day
Chris
Pingback: WordPress Plugin Releases for 09/03 | Wordpress Blog NL
Great work! Greetings from Ukraine!
hello, can someone confirm that it must say: define(‘ENABLE_CACHE’, ‘yes’); and not define(‘ENABLE_CACHE’, ‘true’); ?
And besides is there an updated version for eaccelerator available anywhere?
@Neil, @ovidiu: As it turns out, the ENABLE_CACHE define isn’t needed anymore. I just double-checked, and all that is required is for the object-cache.php file to be present in the wp-content directory. If it’s there, WP will load it instead of the default wp-includes/cache.php file.
One more thing. Since there’s also a plugin for EAccelerator, how about updating that too?
Peace,
Gene
Ideally I’d just like to be able to set a var and it prefixes my keys with like “viperblog_” so when I’m viewing the XCache admin interface I can tell the source.
It’s not a hard fix (few lines of code) and I may just do it myself though.
@Gene Steinberg
you are right, i will have a look at it and post the link after my visit at the dentist in some hours.. 😉
Thank you very much Dougal
I’ve got several WordPress 2.6.1 blogs running on my co-located server, each running under a different domain name with virtual hosting, and different directories. I found after installing your update that all the the sites forwarded to only one domain name until I deleted the object-cache.php file. Haven’t seen that problem before this update.
Todd, did you tried to set the blog_id to a different var in each blog?
Gene:
http://www.pctreiber.net/files/eac-object-cache.tar.gz
But i am not quite sure if it works well, just try.. i do hope it works for eac.
could someone confirm, that using more than wp-installation with different user-tables (i.e. not using the same username/password combinations on the installations!!) works fine? I can’t imagine this caching solution (with global user/userlogin) could work.
I tried the version on an EAccelerator installation. It seems functional, but I’ll await further experimentation and let you know.
Peace,
Gene
Well crud. I figured the solution to problems with a cache shared by multiple blogs would be to base the object cache key on something unique to each site. The obvious candidate would be to use something like:
The problem is, that get_option() calls apply_filters(), which isn’t loaded (from plugin.php) at the point that the object cache is defined.
So, other than manually editing the object cache code to set a unique key for each blog you install it on, I’m stuck for ideas. Anyone?
I suppose you could query the db directly (with $wpdb), but I had hoped to find a cleaner solution.
Dougal,
Thanks for this work. I was trying to track down a bug in wp_count_comments() and I noticed that there was this new api call wp_cache_add_non_persistent_groups() that seemed related. I googled for it and eventually found your site.
Anyway, I wanted to mention to you that I had found another issue specific to WordPressMU that seems to have an issue with the orginal object cache from neosmart, as well as yours.
Namely, from my debugging, it appears as if the “site-options” group is actually serialized in the wpmu-core, and so the default behavior of maybe_serialize() and maybe_unserialize() will break objects cached in the site-options group. My fix to the problem was to add if ($group !== “site-options”) {…} around these calls in set() and get().
You might want to check this out.
OK, one more thing: Some way I can check to see if it’s working? Don’t see much of a change.
Peace,
Gene
Pingback: WordPress Plugin Releases for 09/03 | Credise
OK, EAccelerator version doesn’t really work right. The forum stops loading after a few hours. The older version, 0.6, seems better. 😀
Peace,
Gene
Dougal, what about this:
global $table_prefix;$cacheprefix = DB_NAME . '_' . $table_prefix . '_' . $key;
(or similar)
No DB query or anything else required and that should result in unique prefixes.
@ Viper007Bond:
Ah, excellent idea! DB_name + prefix is unique enough to do the trick. Thanks, I’ll try that out when I get a chance.
Let me know when you get the multiple blog issue figured out 🙂 When you do i’ll be able to use it on my own server, and then I’ll switch over 🙂 Thanks a ton!
Pingback: Rauru Blog » Blog Archive » WordPress ? XCache ?????
Okay, I’ve updated and version 0.7d is now available for download. This version uses a combo of DB_NAME, $wpdb->prefix, and $blog_id to create keys which should be unique, even between multiple installs of WP or WPMU on a shared server.
I’d like for the brave amongst you to give it a try, and let me know if there are still any issues. I’m particularly interested in how (if?) it works with WPMU.
Any hope also for a fixed EAccelerator version?
Peace,
Gene
I had the multiple blog install issue, which took about 12 hours to create the error. I’ll let you know probably tomorrow how well this revision works. Thanks Dougal for all your hard work.
Hi Gene,
i will update the eaccelerator stuff tomorrow if Todd (and maybe other people) tell us if it works, of course. Do not think i let you standing outdoor in the rain alone 😉
i was too slow for editing my post
here is the “updated” eacelerator version
http://www.pctreiber.net/files/eac-object-cache.tar.gz
apc version should be:
http://www.lazybrain.de/wordpress-apc-object-cache-modifiziert.html
I’ll let you folks know if the EAccelerator version causes any problems. Previous versions have caused the blog to stop rendering after a few hours. Deleting the plugin was the only fix.
Peace,
Gene
Seems solid after 24 hours. How do I confirm it’s working?
Peace,
Gene
I’ve been testing the 0.7d version on a multiple blog install server, and I haven’t had any problems.
It’s been working great on my 2 blog system as well, thanks a ton 😉
@Vahid: do you have the same usernames on both blogs?
This is my case and where this plugins ceases to work: i have two blogs with a user “admin” (both as the same first user in the database, id=1). When i install this object-cache and open blog#1, it saves this object-cache: “users:1”. Now, if i try to access the administration of blog#2 with the username “admin” (but different password) i get a “access denied”.
I do think, that it’s logical, because they both access the same “users:1”, where they expect different data. I think the only blogsystem that could use the logic of global user-data is wordpressmu.
I hope you can understand my English.
I haven’t had any issues either.
Omar,
My multiple blogs are installed on the same server, with separate directories, separate databases, and different admin usernames.
My Blogs are on the same server, different directories and mostly the same usernames and passwords.. with the apc version i got no problem. eAc isn`t running well on my setup and xcache.. mh. i would give it a chance but i am not concerned that it would run faster than apc.. and the 2.x trunk of xcache give me white blog sites. sorry for my english.
Well It was working for for a week then suddenly when one of my site’s went down so did the xcache plugin lol. IT seems to have cached the time when it was down so the site caches a broken version of it. Any ideas? I had to remove it from my other site and only have it on my major site for it to work.
My final comments on the xAccelerator version:
I fail to see any evidence that it has any measurable impact on the performance of my WP blog. None, zip, zilch.
After a few days, the blog stops displaying, so I have to restart Apache manually (it’s configured to restart each 24 hours, at midnight, to clear the cache).
So I don’t see where any of this is taking us anywhere. I’d love to see an improvement, but you’re not there yet.
Peace,
Gene
In my case, the server has 4GB of RAM, a dual-core processor and server loads are generally pretty low. Performance is fine without the plugin. It doesn’t change with it installed, only the site stops after a few days, unless I restart Apache.
My conclusion here is that the plugin has a deleterious effect. I wish it were otherwise.
Peace,
Gene
The strangest thing is that this plugin seems to work fine for me on my WPMU installs, but it always takes away all the links that are specific to WPMU in terms of the overall “site-admin”. It doesn’t affect any blog admin, but it does strip the overall admin from making changes to the overall service without disabling the plugin. Any ideas?
Downloaded it. Very usefull plugin. Thanks for sharing!
Pingback: WordPress Wednesday Kick Off | geek ramblings
Can this be used along with the WP-supercache plugin?
And I meant to add on a regular wordpress install as well???
Pingback: Dougal Campbell: WordPress Wednesday Kick Off | Aslifmbiz Blog
Just installed 0.7d, and it's working fine with my blog. Thanks.
Pingback: Utilizing Object Cache Using xCache | WPVita
I know this post is a year old, but it’s the best/most recent plug-in I could find for using xcache with WP. I just installed it for WP 2.8.4 and it appears to be working great. I don’t quite understand how WP recognizes/uses the plug-in just by uploading the file to the wp-contents folder, but I’m glad it does. Thank you for sharing your updated plug-in.
Hi, is this working with wordpress 8.4
thanks.
Pingback: Server Reconfig
Hi, i’m using this plugin on WP 2.8.6 and it seems to work very well, lowering query numbers to a 1/3 factor (from about 60 to about 20). But I notice a strance behaviour: admin password is not recognized at all and i must reset it to obtain admin access again. With all other users, there are no problems.
Can someone point me in the right direction to resolve this issue?
Thanx!
Only one note: if I clear cache content fromXcache admin panel, WP admin access works again.
I’ve found the problem. Don’t know why and don’t know where, WP adds “users”,”userlogins”, “usermeta” to the “global_groups” array and so your plugin store those data with an empty prefix . So, when you run multiple WP on multiple virtualhosts on the same machine, you’re not able to have 2 admin user (or users with the same login) accesses cached at the same time. “Global_groups” (necessary on a WPMU installation that shares authentication parametrs between sub-blogs) should be empty in this case.
As a workaround i’ve patched your code from
function wp_cache_add_global_groups( $groups ) {
global $wp_object_cache;
$wp_object_cache->add_global_groups($groups);
}
to
function wp_cache_add_global_groups( $groups ) {
global $wp_object_cache;
return;
//$wp_object_cache->add_global_groups($groups);
}
It resolves my issue but don’t know if this works on a WPMU installation also (as you manually add global groups at WP_Object_Cache object creation.
Hi, I couldn’t find the link to download the plugin it shows “[drain file 16 show default_show]” instead.
Thanks!
Sorry about that. For some reason, the Drain Hole plugin seems to deactivate itself from time to time. Check again, you should see the download link now.
Pingback: How to optimize and speed up Wordpress - Reaper-X
So in general this should do what the wp-cache plugin does correct?