Full page caching in TXP core

merz1 · 2009-05-21 16:01:02

Just read that article Boost your Drupal site! and was impressed by the general concept in ‘The Basics’ and the points listed in ‘A Little More Detail’.

asy_jpcache is working fine in my TXP 4.0.8 so far but I think it is about time to integrate full page cache handling into the core feature set (didn’t find anything about that in the forum threads).

wet · 2009-05-26 08:09:55

merz1 wrote:

asy_jpcache is working fine in my TXP 4.0.8…

Counting “it’s about time” as half an argument, what else would we gain?

merz1 · 2009-05-26 10:42:36

@Robert Thanks for the question :)

1st of all the idea came up because I was testing some pages and plug-ins in a pretty complicated environment (for me). I always forgot to purge the cache and I also didn’t use the simplest solution to just delete the cache entry. Dumb I know but I would have loved a simple ‘turn cache off’ button.

My main problem were integrated single RSS feeds via Simple Pie and cached update scripts (eg asv_tumblelog_updatefeeds=1) but others may have different issues.

OK, but I think this is my personal stack of arguments for a core integration (@all Remember: We are talking full page cache):

My favorite: I like the idea to 1st lookup a static .html page via .htaccess. This way you could realize a perfect maintenance mode. Even the database could be offline.

The rest. No order intended:

Better cache control for plug-ins via core hooks.
Cache integrity: A single cache control center via hooks. Example: Every plug-in using external sources (or embedded PHP applications) eg SimplePie, the RSS parser, could read a ‘purge signal’ to delete the RSS cache.
A forced cache option for pages and single articles: Save and write to cache, save and don’t cache.
More granularity: Cache this section, don’t cache that section.
User cache: Own cache content/directory for logged-in users.
Fast preview in edit mode: Save, cache & view draft versions much faster. (The draft preview mode is awesome but the time it takes to save & view the article sometimes sucks.)
Collision handling for plug-ins. Example: A plug-in reading referrers and rendering parts of the page depending on a referrer could throw a warning (admin side).
Different cache lifetime cycles. Example: Cached CSS files only need to be updated by a forced refresh or by saving a new version.

Last edited by merz1 (2009-05-26 10:43:13)

Neko · 2009-05-26 13:11:58

I like the idea of having a hassle free caching solution coded into the core. But I wouldn’t mind to have the same solution released as a ransomware (or commercial or whatever) plug-in that actually works without tweaking it and/or having to read 26 pages of a thread in order to find out what’s wrong and how to fix it. And that will be actively maintained. I’d be happy to donate a few bucks in case. I’m sure I’m not alone.

merz1 · 2009-05-26 14:37:05

@Neko Well, asy_jpcache is free and works hassle free, once installed and tested. I had it running multiple times in the last years for ~6 weeks without the need to look at the cache.

As Robert already mentioned my “it’s about time” is only half an argument and meant to be understood as a request for a concept for future changes how TXP might handle full page caching via core.

Last edited by merz1 (2009-05-26 14:38:14)

FireFusion · 2009-05-26 14:47:50

There are many things that can go wrong with that plugin. Everytime install it i find myself rereading that topic to remember how to fix them. An updated plugin would be good.

merz1 · 2009-05-26 15:29:58

FireFusion OK, I count Neko and you as two more votes that “it’s about time” in the sense as said in #5. Thanks :-)

More ideas or votes re. #1 and #3?

Last edited by merz1 (2009-05-26 15:30:28)

hcgtv · 2009-05-26 15:51:39

Markus,

With APC caching your PHP scripts, MySQL caching your queries and Apache gzipping your pages, what would we gain with a core caching solution? Have you run tests using the asy_jpcache plugin, like Apache bench or something?

I’m not against a cache, I’m just wondering what performance gains are to be had. Textpattern is so small, as opposed to other systems that benefit from a cache because they are a bit complex, Expression Engine comes to mind.

Neko · 2009-05-26 16:12:36

merz1 wrote:

@Neko Well, asy_jpcache is free and works hassle free, once installed and tested. I had it running multiple times in the last years for ~6 weeks without the need to look at the cache.

Oh, sorry. Probably it’s because I don’t use that plug-in anymore, so my experience might be a bit outdated. Last time I checked, however, it needed a fix in order to operate correctly under certain conditions (IIRC, something about blank pages on Firefox) and also, again IIRC, Artagesw reported it didn’t return the correct headers on events such 404. Which might be a bit of a problem SEO-wise, maybe? I don’t know if these two issues are still relevant today, tho.

As Robert already mentioned my “it’s about time” is only half an argument and meant to be understood as a request for a concept for future changes how TXP might handle full page caching via core.

Yes, well in my very limited experience it should help a lot unloading resources on very static sites, such as corporate stuff, brochure sites, and so on. But also on blogs and stuff. As you can see I’m not very opinionated due to my limited understanding. But I guess cache is good. :)))

hcgtv wrote:

With APC caching your PHP scripts, MySQL caching your queries and Apache gzipping your pages, what would we gain with a core caching solution? Have you run tests using the asy_jpcache plugin, like Apache bench or something?

Oh, that’s a very interesting point. Is the stuff you mentioned “on” by default on hosts such as Joyent? I mean APC, whatever that is, and MySQL caching.

I didn’t run tests but with asy_jpcache pages used to load like they were stored on my computer’s HD.

Last edited by Neko (2009-05-26 16:15:39)

hcgtv · 2009-05-26 16:48:13

Neko wrote:

Oh, that’s a very interesting point. Is the stuff you mentioned “on” by default on hosts such as Joyent? I mean APC, whatever that is, and MySQL caching.

I don’t know what Joyent runs, but I imagine they have the Zend cache on. I tested all kinds of PHP caching mechanisms and I settled on APC for my home server. This particular server ran my sites for about 3 years, before I decided to upload them to Dreamhost.

Let’s take a site that gets about 100 visitors a day, a cache is overkill. Now a site that gets 100,000 visitors a day would benefit from a cache but would not last too long on a shared host anyway. So if you really need a cache, then you have to go to a VPS or a dedicated server, which would allow you to turn on all kinds of goodies to make your site pop.

artagesw · 2009-05-26 18:25:08

hcgtv wrote:

Markus,
With APC caching your PHP scripts, MySQL caching your queries and Apache gzipping your pages, what would we gain with a core caching solution? Have you run tests using the asy_jpcache plugin, like Apache bench or something?
I’m not against a cache, I’m just wondering what performance gains are to be had. Textpattern is so small, as opposed to other systems that benefit from a cache because they are a bit complex, Expression Engine comes to mind.

Actually, quite a bit is to be gained. Locating and returning a static html file is 1 to 2 orders of magnitude faster than even the simplest dynamically generated page. APC opcode caching does not prevent the need to fire up PHP and execute PHP code on every web request. MySQL query caching does not prevent the overhead of connecting to and communicating with the database server. Dynamically compressing (gzip) pages requires higher CPU utilization on the server, not less. All of these techniques are useful and important for maximizing the performance of dynamically generated pages (i.e. pages not yet cached). But the advantage of a static page cache is that you do all that work only once for a given page.

And although asy_jpcache works pretty well, it still requires loading and executing of PHP code. A static full page caching mechanism (whether built into core, which I advocate, or as a plugin), would be much faster than asy_jpcache and require less less memory to serve cached page requests.

hcgtv · 2009-05-27 02:17:30

artagesw wrote:

Actually, quite a bit is to be gained. Locating and returning a static html file is 1 to 2 orders of magnitude faster than even the simplest dynamically generated page.

With today’s quad core servers, dynamic pages are plenty fast. I hear you though, everything I mentioned does require processing but I’m satisfied with the speed of my sites. Some of my sites are dynamic in nature, RSS feeds, date/time, weather, random images, google ads and such. Doing something like EE, where you can cache certain areas of a page seems like a lot of work for little speed benefit.

Caching for the sake of handling more visitors would make sense, but then you’re looking at a move to a VPS anyway should the traffic increase. On a very graphical site, a text cache only goes so far, pretty soon your disk i/o rings bells at your hosting provider.

A static full page caching mechanism (whether built into core, which I advocate, or as a plugin), would be much faster than asy_jpcache and require less less memory to serve cached page requests.

A basic solution would be a script that runs wget and mirrors your site to disk. Then you just adjust .htaccess to point your visitors to /static/index.html. A poor man’s full page caching :)

Textpattern CMS

Textpattern CMS support forum

#1 2009-05-21 16:01:02

Full page caching in TXP core

#2 2009-05-26 08:09:55

Re: Full page caching in TXP core

#3 2009-05-26 10:42:36

Re: Full page caching in TXP core

#4 2009-05-26 13:11:58

Re: Full page caching in TXP core

#5 2009-05-26 14:37:05

Re: Full page caching in TXP core

#6 2009-05-26 14:47:50

Re: Full page caching in TXP core

#7 2009-05-26 15:29:58

Re: Full page caching in TXP core

#8 2009-05-26 15:51:39

Re: Full page caching in TXP core

#9 2009-05-26 16:12:36

Re: Full page caching in TXP core

#10 2009-05-26 16:48:13

Re: Full page caching in TXP core

#11 2009-05-26 18:25:08

Re: Full page caching in TXP core

#12 2009-05-27 02:17:30

Re: Full page caching in TXP core

Board footer