Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2017-07-25 13:51:38

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

The most costly tags in terms of performance/queries

Hi,

Might be a question for the developers amongst you. Now I have the lovely etc_cache plugin available, I’d like to cache snippets containing tags that cause heavy workload/database queries, where I can. What are the worst culprits tag-wise for this?

Cheers!

Offline

#2 2017-07-25 17:26:28

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: The most costly tags in terms of performance/queries

Switch to debug mode and look at the tag trace in the bottom of the HTML source.
How you use a tag probably influences performance more than which tag you use.

Offline

#3 2017-07-25 18:00:46

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: The most costly tags in terms of performance/queries

Ah, ok thanks Ruud – will try that

Offline

#4 2017-07-26 08:16:06

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: The most costly tags in terms of performance/queries

OK, selective caching definitely helps with some of the list-type tags (<txp:artlcle />, <txp:file_download_list>, etc.).

Tag trace summary on my site homepage before caching:

<!-- Trace summary:
Runtime   : 55.89 ms
Query time: 11.03 ms
Queries   : 33
Memory (*): 4305 kB
-->

Tag trace summary on my site homepage after caching:

<!-- Trace summary:
Runtime   : 47.06 ms
Query time: 6.62 ms
Queries   : 17
Memory (*): 4026 kB
-->

Good stuff!

Offline

#5 2017-07-26 09:34:55

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: The most costly tags in terms of performance/queries

A small hint: need to take the numbers after the second page load, otherwise the results of the comparison may not be correct.


aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#6 2017-07-26 09:38:36

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: The most costly tags in terms of performance/queries

makss wrote #306455:

A small hint: need to take the numbers after the second page load, otherwise the results of the comparison may not be correct.

Er, OK. There is only one summary in the tag trace comments (4.7dev) – do I need to look elsewhere?

Offline

#7 2017-07-26 10:21:56

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: The most costly tags in terms of performance/queries

In the testing mode, only summary information is available. In debug mode, there is detailed information.


aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#8 2017-07-26 10:24:28

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: The most costly tags in terms of performance/queries

I was in debug mode – I basically went through every item listed in the tag trace comments and cached the ones that were giving highest execution times. Probably further gains could be made, but that’s good enough for me I think. Thanks makss.

Offline

#9 2017-07-26 10:44:03

etc
Developer
Registered: 2010-11-11
Posts: 5,087
Website GitHub

Re: The most costly tags in terms of performance/queries

The usual suspects for me would be list tags with limit="999" constructions. On the individual side, date/time related tags (like <txp:posted />) can be rather slow because of timezone/locale conversions.

I think, @makss meant that you should compare the debug figures after the page reload, since some servers cache db queries. Also note that the OO debugger takes some time itself, so these figures are slightly biased.

Offline

Board footer

Powered by FluxBB