etc_cache: cache trying hard to be smart

etc · 2021-02-14 21:14:18

demoncleaner wrote #328866:

OK first things first. Do I understand you correctly that normally by installing your plugin it should automatically create a “cache” folder in the root?

No, it would be created (if enough permissions) when someone visits a page.

For testing purpose I wrapped <txp:etc_cache id=“heavycode”> around my “page” and in extension tab I can see that it is caching something there.

Here… You must install etc_static, not etc_cache. They have not merged yet (save on my laptop), sorry for misunderstanding.

etc · 2021-02-14 21:15:53

demoncleaner wrote #328867:

I get bool(false) when I try this.

Then the plugin will not be able to create/delete cache folder, but if you create it manually and give it 777, it should work (up to a warning maybe).

demoncleaner · 2021-02-14 21:21:21

Thanks a lot for your support. Meanwhile I installed etc_static and everything worked like expected. I am fiddeling around with it right now. But it seems it does what I was looking for. So etc_cache is obsolete for me here or do they work in conjunction?

demoncleaner · 2021-02-14 21:25:22

One last thing. I am experiencing formating problems in the cached version/URL. All my Umlaute are messed up. For example erklÃ€re instead of erkläre. Ist that a UTF8/ISO problem?

etc · 2021-02-14 21:32:34

demoncleaner wrote #328870:

So etc_cache is obsolete for me here or do they work in conjunction?

You can uninstall it and reinstall later when both will merge.

demoncleaner wrote #328871:

All my Umlaute are messed up. For example erklÃ€re instead of erkläre. Ist that a UTF8/ISO problem?

Ah. I will test.

demoncleaner · 2021-02-14 21:58:42

I added

$out = utf8_decode($out);

At the end of your code and it works fine for me now.

etc · 2021-02-14 22:24:49

demoncleaner wrote #328873:

I added

$out = utf8_decode($out);

At the end of your code and it works fine for me now.

Good to know, thanks. But not everyone would like to convert UTF-8 to ISO-8859-1.

Also, you’ll need to modify l.53 and below as follows if you use non-ASCII characters in URL:

    $cache = 'cache/';
    $dir = explode('/', ltrim($pretext['req'], '/'));

    foreach ($dir as &$p) if ($p !== '') {
      $p = rawurldecode($p);
      if ($p !== sanitizeForFile($p)) return;
    } else {
      $p = 'index';
    }

Pat64 · 2021-02-15 04:11:40

@Oleg:
If your plugin includes an HTML page source minifier we could get a cutting edge solution IMHO (I didn’t notice any performance gain compared to pat_speeder for example).

etc · 2021-02-15 09:52:40

Pat64 wrote #328875:

If your plugin includes an HTML page source minifier we could get a cutting edge solution IMHO

This is a nice idea, but I try to leave to users as much choice as possible. Some might want to have their pages minified, others prefer them prettified. Nothing stops you from including <txp:pat_speeder /> in the source to compress the output. Some delegate compression to apache server.

(I didn’t notice any performance gain compared to pat_speeder for example).

We should be clear here. A typical web access can be split into 3 main parts: server-side page generation, network transit and browser treatment. etc_static reduces the first part drastically: ~60ms for dynamic pages vs 6ms for their static copies on my laptop. The ratio should be the same on a ‘true’ server, but the figures could be divided by 2: 30ms vs 3ms. So you gain ‘only’ 30ms (also because txp is fast), which might be equalled by using compression. The main advantage of static pages is that you spare processor cycles and save the planet. Yo :-)

philwareham · 2021-02-15 10:06:02

etc wrote #328877:

The main advantage of static pages is that you spare processor cycles and save the planet. Yo :-)

Also, you could theoretically tell your CDN to treat the cached pages directory as static assets. Effectively the model of, for example, Eleventy + Netlify – or maybe even Jamstack (a.k.a using a headless CMS). Both big trends at the moment.

FYI: I’m also looking at CDN stuff as part of the image improvements planned for Textpattern (offloading your images to a CDN directly from within the control panel). The libraries already exist – we just need to work out how to implement them well in Textpattern.

Pat64 · 2021-02-15 11:22:40

etc wrote #328877:

We should be clear here. A typical web access can be split into 3 main parts: server-side page generation, network transit and browser treatment. etc_static reduces the first part drastically: ~60ms for dynamic pages vs 6ms for their static copies on my laptop. The ratio should be the same on a ‘true’ server, but the figures could be divided by 2: 30ms vs 3ms. So you gain ‘only’ 30ms (also because txp is fast), which might be equalled by using compression. The main advantage of static pages is that you spare processor cycles and save the planet. Yo :-)

I was always in favor to save the planet. Keeping all technical stuff the smaller I can (I have never used along my life a large CSS framework (like Twitter Bootstrap despite this fact: it’s an extremely fast prototyping tool for web agencies), nor jQuery for example). 🌍

I know TXP is an extremely fast CMS (the reason why I’m using it).

Setting on the memcache within a real server gives me a performance gain of 7 points (according to all online performance testing tools).

So based on my observations using your (excellent) plugin on an in production website, the problem comes with page weight, first (what a browser receives as an HTML document).

Last edited by Pat64 (2021-02-15 11:31:02)

philwareham · 2021-02-15 12:13:03

So based on my observations using your (excellent) plugin on an in production website, the problem comes with page weight, first (what a browser receives as an HTML document).

Well, yes and no – there are plenty of factors that impact the site speed, the exact issue varying depending on location. Obviously you are right that the bigger the payload the slower the site, but HTML itself generally isn’t the main offender for that (that’d be media and JavaScript).

Take for example Textpattern.com, which is hosted on a server in Europe (and is very well optimised – although no caching in place, yet) and the speed test was also conducted in Europe. You can see the majority of the time to render the page is ‘wait’, while Web browser is waiting for data from the server, and the server does the dynamic CMS build part, Gzip, etc. of the HTML ready to send it (~78ms). That ‘wait’ period could be improved substantially by caching the page as a flat file (I’d have to test it, but I’d assume so)…

Speed test - Europe

Now, take that same test from Australia, you can see a considerable amount of time is now spent making the initial handshake with the server (just over a second, in fact). Again, by caching the page and also using a global CDN to serve it, you’d bring that time way down.

Speed test - Australia

Note the above diagrams show just the HTML part of the load process – I’ve omitted everything else.

etc · 2021-02-16 14:03:26

Well, here it is. You MUST uninstall etc_static before. Then install and (re)activate etc_cache and visit Advanced prefs for basic configuration.

Even if you don’t need static cache and have etc_cache already installed, you might want to update it for improved admin tab markup.

etc · 2021-02-17 16:12:35

jakob wrote #320095:

I’m curious: I get why the txp:tag can’t be added to the filter field in the Extensions » etc_cache panel, but if it were possible to pass the filter as an attribute of the tag, like you can with reset, would the tag-in-tag variant work? My thinking was that the tag-as-attribute would be processed first and the results passed to etc_cache.

Finally, in today’s version one can set filter on the public side via id/form-less <txp:etc_cache /> blocks:

<txp:etc_cache reset="article_save">
"article_save":{"ID":<txp:article_id />}
</txp:etc_cache>

will make all subsequent cached blocks in the current article be updated only on this article’s update.

etc · 2021-02-18 13:21:03

After many trial and error .htaccess cycles, I have managed to make static cache work on my plugins site. The lines to add were in my case

    RewriteCond %{REQUEST_METHOD} =GET
    RewriteCond %{QUERY_STRING} ^$
    RewriteCond /path/to/site/cache/$1 -f [OR]
    RewriteCond /path/to/site/cache/$1index.html -f
    RewriteRule ^(.*) cache/$1 [PT,L]

    RewriteCond %{REQUEST_METHOD} =GET
    RewriteCond %{QUERY_STRING} ^$
    RewriteCond /path/to/site/cache/$1.html -f
    RewriteRule ^(.*) cache/$1.html [PT,L]

where /path/to/site is the value of $path_to_site variable from Diagnostics. Now I get ~ 180ms/80ms ratio between dynamic and static pages. Not as much as Varnish could give, but better than nothing.

Textpattern CMS support forum

#61 2021-02-14 21:14:18

Re: etc_cache: cache trying hard to be smart

demoncleaner wrote #328866:

#62 2021-02-14 21:15:53

Re: etc_cache: cache trying hard to be smart

demoncleaner wrote #328867:

#63 2021-02-14 21:21:21

Re: etc_cache: cache trying hard to be smart

#64 2021-02-14 21:25:22

Re: etc_cache: cache trying hard to be smart

#65 2021-02-14 21:32:34

Re: etc_cache: cache trying hard to be smart

demoncleaner wrote #328870:

demoncleaner wrote #328871:

#66 2021-02-14 21:58:42

Re: etc_cache: cache trying hard to be smart

#67 2021-02-14 22:24:49

Re: etc_cache: cache trying hard to be smart

demoncleaner wrote #328873:

#68 2021-02-15 04:11:40

Re: etc_cache: cache trying hard to be smart

#69 2021-02-15 09:52:40

Re: etc_cache: cache trying hard to be smart

Pat64 wrote #328875:

#70 2021-02-15 10:06:02

Re: etc_cache: cache trying hard to be smart

etc wrote #328877:

#71 2021-02-15 11:22:40

Re: etc_cache: cache trying hard to be smart

etc wrote #328877:

#72 2021-02-15 12:13:03

Re: etc_cache: cache trying hard to be smart

#73 2021-02-16 14:03:26

Re: etc_cache: cache trying hard to be smart

#74 2021-02-17 16:12:35

Re: etc_cache: cache trying hard to be smart

jakob wrote #320095:

#75 2021-02-18 13:21:03

Re: etc_cache: cache trying hard to be smart

Board footer