Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Talk by Rasmus Lerdorf
I’m watching this right now, but it’s a great talk by Rasmus about PHP performance. He uses Wordpress as an example in certain parts, but his suggestions are easily useful for Textpattern and any programmer.
Offline
Re: Talk by Rasmus Lerdorf
variaas wrote:
talk by Rasmus about PHP performance.
This is so spooky. Myself, net-carver and Jeff Soo were discussing TXP’s performance and methods to improve it, over a pub lunch today. Thanks for the link.
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: Talk by Rasmus Lerdorf
Interesting, both the video and the fact that performance is being discussed by key TXP players (care to share the idea’s?)
Offline
Re: Talk by Rasmus Lerdorf
net-carver suggests parsing forms and page templates to php code when saving them, then running eval() on page render. Pre-parsed forms and pages to be stored in db (as with articles vis-a-vis Textile), and possibly cached in the file system as well.
Code is topiary
Offline
Offline
Re: Talk by Rasmus Lerdorf
I’ve considered doing something like that as well, but without using eval(), because an opcode cache apparently doesn’t give performance improvements when using eval().
Offline
Re: Talk by Rasmus Lerdorf
I’m not well versed in the way TXP does things in this area right now (it may already do some of this), but does a static/filesystem cache work? e.g. on save of form, cache it to the file system in its PHP form:
echo '<span class="title">' . title(array()) . '</span>';
echo '<p>' . body(array()) . '</p>';And then do this kind of thing:
static $txpforms;
if (isset($txpforms[$current_form])) {
$content = $txpforms[$current_form];
} else {
if (file_exists('/preparsed/'.$current_form.'.form') {
$content = file_get_contents('/preparsed/'.$current_form.'.form');
} else {
$content = parse(fetch_form($current_form));
}
$txpforms[$current_form] = $content;
}
...
// eval or otherwise execute all the contentSo every time a form is requested it checks the static array first, then the filesystem and finally the DB, and caches the result in the static array. It could write the form to the filesystem after line 8 as well, though that probably slows things down unnecessarily so I’d suggest the cache only be updated on save. Or is that the same animal as you still need to eval() things?
Things get a bit trickier with tags-in-tags in your forms/pages but there’s (probably) no reason the parser couldn’t substitute those as arguments as well or cache them as ‘includes’ or whatever.
Not sure. Haven’t thought it through much yet. Any other way to preparse/store it so we don’t need to eval()?
Last edited by Bloke (2010-08-05 10:00:23)
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: Talk by Rasmus Lerdorf
I suspect the most likely candidate for improving performance is removing the eval() from the plugin loading and instead store the plugin code on disk and simply include it from a file. This will mostly help those that have a lot of plugin code activated in their TXP installs.
Offline
Re: Talk by Rasmus Lerdorf
The way TXP loads pretty much everything public side form the DB is likely to be a big bottleneck. An intermediate cache to the file system that would just be included() would probably help that a lot.
You could probably have the admin create the PHP file system version on saves from admin and have the front end simply load it if enabled, that way you don’t even suffer the logic overheard.Hooks to be able to plug in cache front ends like memcache would be awesome too.
Shoving is the answer – pusher robot
Offline
Re: Talk by Rasmus Lerdorf
The plugin load speed did crop up during conversation too and we came to the same conclusion as Ruud.
iirc, it’s the way xpattern approached things — from what I remember, pretty early on the notion of rvm_css was built into the core and then plugins were put in the filesystem instead of (or in addition to?) the database for performance reasons. No reason we couldn’t do likewise here at some point if it proved to speed things up tremendously. One day I’ll profile TXP to see where the bottlenecks lie in different types of sites with/without hordes of plugins…
Last edited by Bloke (2010-08-05 22:48:56)
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: Talk by Rasmus Lerdorf
Bloke wrote:
No reason we couldn’t do likewise here at some point if it proved to speed things up tremendously.
Depends how it’s done. If on every request TXP checks if the file exists or checks if it’s already included, it won’t help that much. But if it’s more of a blind and relies that everything works (user doesn’t tingle the files directly), it helps more.
Offline
Re: Talk by Rasmus Lerdorf
I think the best approach for improving performance of a system like Txp is intelligent caching. It is far less invasive and therefore less likely to introduce subtle compatibility bugs. I have built such a system for another project I have been working on, and it works splendidly. Plugins are cached to disk and simply included as needed. In addition, full page caching sends parsed pages to a cacher (itself a plugin, which supports database, memcached and file system as the backend cache). If the file system is used as the backend page cache, all it takes is a few clever mod_rewrite rules to serve a site with static site speed. Unlike with asy_jpcache, there is not a single line of PHP code executed for cache hits.
My intent was to add similar functionality to Txp 4.3, but that seems unlikely as of right now. Looking like more of a 5.0 feature.
Offline