PHP Caching for Dummies

[markb14391]

Hi,

I'm setting up lots of WordPress sites including WPMU and BuddyPress, and it's highly recommended to use PHP caching (eAccelerator, xcache, etc.).

However, I've seen a variety of info (not all of it consistent) saying that suphp does not allow acceleration...and suphp is what I use. I've seen various other messages on the topic of caching/acceleration containing various opinions. And I'm confused. :-(

Can someone post an overview that definitively shows how to set up PHP caching in the most secure possible way?

Thanks,

Mark

[cPanelDavidG]

If you were to employ application-level caching, you can avoid any incompatibility issues with fastcgi/SuPHP/etc.

WordPress, in particular, has many useful and robust plug-ins for [application-level] caching.

[markb14391]

Thanks. I was wondering about that. I know that many people use the WordPress Super Cache plug-in. However, WordPress (at least WPMU/BuddyPress) recommends using that plug-in in conjunction with something like eAccelerator or xCache. So if I use the plug-in, I assume I'll get good results but not as good as the plug-in and general caching. Are there any other ways to get the benefits of both kind of caching? I'm thinking that suphp is still best for me overall, so I may have to sacrifice.

Or is WP wrong, and maybe I really won't gain anything more by using two kinds of caching?

[cPanelDavidG]

Thanks. I was wondering about that. I know that many people use the WordPress Super Cache plug-in. However, WordPress (at least WPMU/BuddyPress) recommends using that plug-in in conjunction with something like eAccelerator or xCache. So if I use the plug-in, I assume I'll get good results but not as good as the plug-in and general caching. Are there any other ways to get the benefits of both kind of caching? I'm thinking that suphp is still best for me overall, so I may have to sacrifice.

Or is WP wrong, and maybe I really won't gain anything more by using two kinds of caching?

Application-level caching in PHP scripts typically works by first looking if the page is cached. If it isn't cached or the cached version is too old, such mechanisms typically have PHP generate the page as it normally would but then caches that to HTML. This means subsequent requests for that PHP-generated page will be fetched almost as if they were static HTML.

I say almost, because there's that step where the PHP application is used to determine if the static HTML is too old (stale cache) or even exists at all and PHP is used to fetch the generated HTML from cache and use that. Additional acceleration/caching can accelerate these relatively resource-trivial tasks, but the bulk of the work is done by the application-level caching (another reason why it's so attractive).

However, application-level caching does have its downsides. It typically relies on the fact that pages aren't in a perpetual state of flux. WP Super Cache addresses this issue well especially with regards to comments and page/post updates but isn't perfect. For example, if you want to have real-time content such as a visitor counter that displays an updated count for each visit (rather than updating after a reasonably short period of time), that's not handled well with application-level caching.

Bringing this back to cPanel/WHM, application-level caching means you don't need to worry about what does and doesn't work with SuPHP etc. However, if you absolutely need to have something like a visitor counter to be updated in real time, you may be better off with those server-side caching mechanisms such as eAccelerator et. al. but you will need to be more mindful of compatibility concerns.

[markb14391]

Thank you. That's exactly the kind of info I was hoping for. I don't need anything like page counters, so I think the application-level caching will work for me. Thanks for letting me know how effective it can be.

Mark

[Gene Steinberg]

Thank you. That's exactly the kind of info I was hoping for. I don't need anything like page counters, so I think the application-level caching will work for me. Thanks for letting me know how effective it can be.

Mark

As a veteran of eAccelerator and XCache, I have to tell you that the performance improvement on a fast server is minimal, expressed in tenths of a second and never noticeable by the end user.

More to the point, there are tricks. vBulletin lets you use the Datastore feature, to store data in a file cache. The WordPress caching plugins are robust and their upsides and downsides are known.

When you turn off SuPHP, you also create all sorts of permissions issues that you have to work around in setting up your sites. It's not worth the headache and every one of those server-side PHP caches causes anomalous behavior of one sort or another.

I'm done with them.

Peace,
Gene

[markb14391]

Gene,

Thank you for sharing your experiences. Now I feel much better about the idea of keeping suphp and using application-level caching.

Thanks again,

Mark

[Gene Steinberg]

Gene,

Thank you for sharing your experiences. Now I feel much better about the idea of keeping suphp and using application-level caching.

Thanks again,

Mark

I'm happy to list my sites for anyone to check and tell me they have a problem with performance without those server-side utilities (not sure if the cPanel folk would let me though). I couldn't tell any difference myself, although WordPress measures a tenth of a second or two slower in generating a page. Who cares?

Peace,
Gene

[myuption]

This was useful information, thanks!

[GaryT]

xCache is ok - But as xCache mainly runs from the CPU and not the memory, Many Many requests may cause the server load to go high.

I personally would go with Eaccelerater with OPCode, Change the Eaccelerator default folder to something new, Like me its called /dev/ea and then I run a cron every 10 mins to clear this , Yet its very fast pageloads and it does not fill up your memory.

I gone of the idea of suPHP - All the clients I host use wodpress, IPB and VB, So for me FCGI - eAccelerator and Litespeed works extremely well for those sites, Another thing is most people will choose 777 or 755 permissions, Now if you have an auto setup and people upload, They may get errors as they wont know about the suPHP permission settings ( This is some trouble I had ) so this is just one small reason I refused to use it.

suPHP is more secure, Yes but buy removing this and choosing fastCGI /litespeed makes it even more secure and quicker.