Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Performance Anxiety | custom_field loopiness
Thanks, will do. I’ve never hit a performance problem in TXP before, but then I’ve never developed a site with more than 500 articles…
In light of all your comments, it looks to me that I’m jumping through hoops to dynamically generate something that needn’t be. If I hard code the links e.g. <a href="?q=Ceiling">Ceiling</a>
I’ll have a pain-in-the-ass workflow, but way more efficient code.
Of course, all of this is moot if searching across custom_fields using wet_haystack is slow with thousands of articles.
Offline
Re: Performance Anxiety | custom_field loopiness
giz wrote #289355:
If I hard code the links e.g.
<a href="?q=Ceiling">Ceiling</a>
I’ll have a pain-in-the-ass workflow, but way more efficient code.Of course, all of this is moot if searching across custom_fields using wet_haystack is slow with thousands of articles.
Hard-coding the links would make things just a little faster, since you still have to retrieve data and eliminate duplicates from thousands of articles. But doing this admin-side only when articles are updated, as proposed by Jukka (Gocom), would make this work invisible for site visitors. I’d rather put the results in a form, though.
Offline
Re: Performance Anxiety | custom_field loopiness
etc wrote #289356:
Hard-coding the links would make things just a little faster, since you still have to retrieve data and eliminate duplicates from thousands of articles.
By you still have to retrieve data I assume/hope you mean once the site visitor clicks on one of my hard-coded links? By hard-coding the links there would be no extra tag processing (other than calling the form they are in)…?
Offline
Re: Performance Anxiety | custom_field loopiness
I guess I have misunderstood your intentions, sorry. No, there will be no problem if you put all links in a form, but yes, then you delegate computers work to humans.
Actually, 2000 might be not such a big deal. Robert (wet) has written a plugin that can generate thousands of articles at once, for testing.
Offline
Re: Performance Anxiety | custom_field loopiness
Thanks, I’ll try wet_lorem_ipsum – it looks to be what I need.
For the moment I’m using your etc_query solution (so much better than my hack) – it’ll act as a baseline for my performance testing, with Jukka’s solution there as a back-up if the server squeals.
Thanks all for introducing me to new depths of Textpattern. All very useful.
Offline
Offline
Re: Performance Anxiety | custom_field loopiness
giz wrote #289333:
Can someone explain why I couldn’t just wrap ask_cache around my inefficient code? Not that I’ve ever used it before…
I come back to your question: because some visitor has to trigger cache updates, and he/she will have to wait while the inefficient code is processed. Now, why not to update aks_cache automatically, on each article post/save? Here is my proposal:
- Install
aks_cache
and checkReset cache if site was updated
preference onaks_cache
tab. - Wrap your code in some long-living
aks_cache
block, withnoreset=""
. - Install and activate
etc_ping
(below), and filletc_ping
field in Advanced Preferences with one or several comma-separated URLs where youraks_cache
block(s) is (are) visible.
Each time an article is saved/updated, etc_ping
will connect to its URLs and trigger aks_cache
update.
# Name: etc_ping v0.1
# Type: Admin plugin
#
# Author:
# URL:
# Recommended load order: 5
# .....................................................................
# This is a plugin for Textpattern CMS - http://textpattern.com/
# To install: textpattern > admin > plugins
# Paste the following text into the 'Install plugin' box:
# .....................................................................
YToxMTp7czo0OiJuYW1lIjtzOjg6ImV0Y19waW5nIjtzOjY6ImF1dGhvciI7czowOiIiO3M6
MTA6ImF1dGhvcl91cmkiO3M6MDoiIjtzOjc6InZlcnNpb24iO3M6MzoiMC4xIjtzOjExOiJk
ZXNjcmlwdGlvbiI7czowOiIiO3M6NDoiY29kZSI7czo3MzU6InJlZ2lzdGVyX2NhbGxiYWNr
KCdldGNfcGluZycsICdhcnRpY2xlX3Bvc3RlZCcpOw0KcmVnaXN0ZXJfY2FsbGJhY2soJ2V0
Y19waW5nJywgJ2FydGljbGVfc2F2ZWQnKTsNCnJlZ2lzdGVyX2NhbGxiYWNrKCdldGNfcGlu
Z19pbnN0YWxsJywgJ3BsdWdpbl9saWZlY3ljbGUuZXRjX3BpbmcnKTsNCg0KZnVuY3Rpb24g
ZXRjX3BpbmdfaW5zdGFsbCgkZXZlbnQ9JycsICRzdGVwPScnKQ0Kew0KCWdsb2JhbCAkcHJl
ZnM7DQoJaWYoJHN0ZXAgPT0gJ2RlbGV0ZWQnKSB7DQoJCXNhZmVfZGVsZXRlKCd0eHBfcHJl
ZnMnLCAibmFtZSBMSUtFICdldGNcX3BpbmcnIik7DQoJfQ0KCWVsc2VpZigkc3RlcCA9PSAn
ZW5hYmxlZCcpIHsNCgkJaWYoIWdldF9wcmVmKCdldGNfcGluZycpKSBzZXRfcHJlZignZXRj
X3BpbmcnLCAkcHJlZnNbJ2V0Y19waW5nJ10gPSAnJywgJ2V0Y19waW5nJywgUFJFRl9BRFZB
TkNFRCwgJ2xvbmd0ZXh0X2lucHV0Jyk7DQoJfQ0KCXJldHVybjsNCn0NCg0KZnVuY3Rpb24g
ZXRjX3BpbmcoJGV2ZW50LCAkc3RlcCwgJHJzKSB7DQoJaWYoJHVybHMgPSBnZXRfcHJlZign
ZXRjX3BpbmcnKSkgew0KCQkkdXJscyA9IGRvX2xpc3QoJHVybHMpOw0KCQlmb3JlYWNoKCR1
cmxzIGFzICR1cmwpIHsNCgkJCWlmKCFwcmVnX21hdGNoKCcvXmh0dHBzPzovaScsICR1cmwp
KSAkdXJsID0gaHUubHRyaW0oJHVybCwgJy8nKTsNCgkJCWZpbGVfZ2V0X2NvbnRlbnRzKCR1
cmwpOw0KCQl9DQoJfQ0KfSI7czo0OiJ0eXBlIjtzOjE6IjQiO3M6NToib3JkZXIiO3M6MToi
NSI7czo1OiJmbGFncyI7czoxOiIyIjtzOjQ6ImhlbHAiO2I6MDtzOjM6Im1kNSI7czozMjoi
ZDhhN2VkYjc1ZDg3NTBmYWJlMDI5ZDgxODMyNGM4YmUiO30=
Devs: would be great if update_lastmod()
fired a callback.
Update: now allows relative URLs (like index.php?id=1
).
Last edited by etc (2015-05-11 20:17:58)
Offline
Re: Performance Anxiety | custom_field loopiness
etc wrote #289510:
would be great if
update_lastmod()
fired a callback.
Fabulous idea. Can you please raise a feature or submit a pull request and we’ll get it folded in.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Performance Anxiety | custom_field loopiness
Thank you Oleg: great stuff. I’ll give it a whirl and report back with how my performance testing goes.
Offline
Re: Performance Anxiety | custom_field loopiness
Bloke wrote #289511:
Fabulous idea. Can you please raise a feature or submit a pull request and we’ll get it folded in.
Thanks Stef, done. Would be even better if update_lastmod()
were more verbose re the event triggering the update, but it makes 30 requests.
Offline
Re: Performance Anxiety | custom_field loopiness
etc wrote #289513:
Would be even better if
update_lastmod()
were more verbose re the event triggering the update
Thanks. If you have any ideas on callback name/event/step, by all means share them on the Issue page. We could raise a single one and you would have to use the $event
to determine if it’s one you want to intercept, or maybe core could set the $step
as the event for more granular options?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Performance Anxiety | custom_field loopiness
Something like this?
function update_lastmod($event = '', $rs = null) {
...
// $event will be $step, $rs contains article (image, ...) data passed by the caller
callback_event('update_lastmod', $event, false, $rs);
}
This should be granular enough, but we can sleep on it for a while.
Edit: sorry for polluting the thread, maybe move it to Feature ideas?
Last edited by etc (2015-03-27 22:12:17)
Offline