Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#25 2020-11-18 10:43:24

etc
Developer
Registered: 2010-11-11
Posts: 4,529
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

What bugs me more than a slight mean runtime increase is the standard deviation, which is notably larger in 4.8.4. The minima In 4.6 and 4.8 are roughly the same, and the medians are close, but from time to time 4.8.4 yields much longer runs. The difference seems to come from include_once txpath.'/publish/taghandlers.php', but damn if I see why. I have even tried using 4.6 taghandlers.php in 4.8, that did not help much.

Offline

#26 2020-11-18 11:35:02

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,538
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

Taghandlers is huge.

I noticed recently that someone (might even have been you?) did some tweaks there with the few tags we have in classes. Is there something more we could do here as we move forward to use inheritance?

I’m thinking predominantly of things like ‘file_download_list is a list tag that uses the conditional interface’ kind of setup.

In theory, once a base class is in memory, any other tags that are more specific variants of it should only require to load that class and already benefit from what’s already loaded. Classes will increase the memory footprint, sure, but that might give us more performance advantage as we’ll only load tags we need on a page – on-demand rather than injecting all of them into the global namespace every page. Not sure.

Last edited by Bloke (2020-11-18 11:36:21)


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

#27 2020-11-18 17:26:27

etc
Developer
Registered: 2010-11-11
Posts: 4,529
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

If it were just a regular slowdown, I wouldn’t be so surprised (the size matters). But how to explain this:

4.6.2
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    31   34   3.3     31      47
Waiting:       31   34   3.3     31      47
Total:         31   34   3.3     31      47

-----------------------------------------

4.8.4
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    22   39  13.6     31      78
Waiting:       22   39  13.6     31      78
Total:         22   39  13.6     31      78

As you see, median connection times are the same (and min is even better for 4.8.4). But 4.6.2 looks much more stable, while 4.8.4 is skewed to the left, with rare but high max spikes.

Offline

#28 2020-11-19 11:49:57

etc
Developer
Registered: 2010-11-11
Posts: 4,529
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

Bloke wrote #326915:

I noticed recently that someone (might even have been you?) did some tweaks there with the few tags we have in classes. Is there something more we could do here as we move forward to use inheritance?

I have actually done it the other way, considering that loading classes for this little is an overkill and replacing some of them (if_first/last) with plain functions. But for more specific tag groups (like comments) putting them in an autoloaded class is certainly a good idea, needs testing performance-wise.

Offline

#29 2020-11-19 11:53:52

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,679
GitHub

Re: Textpattern 4.8.3 Apache Bench

I realise the A / B testing between versions is relative within the bounds of the same db and PHP setup, but are these tests using vendor-supported PHP releases, out of interest?

Offline

#30 2020-11-19 12:41:45

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,538
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

etc wrote #326944:

for more specific tag groups (like comments) putting them in an autoloaded class is certainly a good idea, needs testing performance-wise.

Yes, I’m not sure of the performance impact. Classes tend to be slower, BUT taghandlers is so big and has so much repetition and pollutes the global function space, that it’s a hog.

If we’re clever with inheritance and create a hierarchy of tags with some interface traits we might be able to mitigate the slowdown by only autoloading the tags needed to process each page. That has to help, surely?

I’m thinking of a similar approach to the UI library whereby the ‘base’ class is loaded on-demand for any front-end tag encountered, and that houses a lot of the functionality like handling attributes and setting up internal class variables for things like $thing. Then maybe interfaces can take over to provide ‘type of’ functionality, and specific database queries or global/URL access do the dirty work. Finally ->render() (and/or magic echo) squirts out the result. Not sure.

That might be the wrong approach. Perhaps we should be looking at factory classes or adapters instead. But either way, it’d be nice to factor out a lot of the repetition. This could be a branch swinging off 4.9, where we can experiment, perhaps?


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

#31 2020-11-19 13:21:51

etc
Developer
Registered: 2010-11-11
Posts: 4,529
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

gaekwad wrote #326945:

I realise the A / B testing between versions is relative within the bounds of the same db and PHP setup, but are these tests using vendor-supported PHP releases, out of interest?

I’m testing on a local XAMPP, PHP 7.4 (after removing magic quotes stuff from 4.6-4.7) fwiw.

Bloke wrote #326946:

Yes, I’m not sure of the performance impact. Classes tend to be slower, BUT taghandlers is so big and has so much repetition and pollutes the global function space, that it’s a hog.

I have trued putting all comments tags in a class without calling them (e.g. article list page). The memory usage is ~200kB lower and the runtime is closer to 4.6, but still more fluctuating (in 4.7 too). Have not compared calling comments tags yet, but this looks promising.

Perhaps we should be looking at factory classes or adapters instead. … This could be a branch swinging off 4.9, where we can experiment, perhaps?

Sure, though you risk to loose me here :-)

Offline

#32 2020-11-19 13:59:28

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,538
Website GitHub

Re: Textpattern 4.8.3 Apache Bench

etc wrote #326947:

I have tried putting all comments tags in a class without calling them (e.g. article list page). The memory usage is ~200kB lower and the runtime is closer to 4.6, but still more fluctuating (in 4.7 too).

Promising indeed, woohoo!

Sure, though you risk to lose me here :-)

Oh don’t be under any illusion I know what I’m talking about when it comes to factories and adpaters :) I know of them and each time I read about them I think, hey they sound like a great – if convoluted and memory-intensive – way to manage stuff. But then I completely fail to see the real-world application in Txp terms and go and do something else instead. Then forget what I learned about them.

My OO-fu is rudimentary at best. For example, I’m struggling to find the best way to factor in an SMTP Adapter to our /Textpattern/Mail classes. I know how to do it and could hack it into our workflow today ready for softly-softly usage in 4.8.4. But it probably wouldn’t be the right approach, because the use of the adapter we have today is the correct way to do it.

I don’t know whether to create a second adapter and modify our existing base mail class to handle the extra requirements of external SMTP transportation, or to do it all in a parallel adapter. I’ll need to read up on best practices (again) and figure it out, which will miss the 4.8.4 boat I expect.


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

Board footer

Powered by FluxBB