Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#97 2015-06-23 15:09:44

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

Re: Making plugins first-class citizens

From the Github comments:

Perhaps best to first decide which parts you want. I can create a new, clean branch if necessary or perhaps it is possible to cherry pick commits

Where you = devs :)

Offline

#98 2015-06-24 14:01:00

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,721
Website

Re: Making plugins first-class citizens

ruud wrote #290611:

Looks like 4.6-dev somehow got a lot slower compared to 4.5.7.

Yes, I can confirm your findings.

http://jessie/
VirtualBox: Intel Dual Core (3.0GHz), 2GB of ram
Debian GNU/Linux 8.1 “jessie” – Apache 2.4.10 – MySQL 5.5.43 – PHP 5.6.9

Textpattern 4.5.7:

bert@jessie:~$ ab -n 100 -c 10 http://jessie/textpattern/
Document Path:          /textpattern/
Document Length:        9797 bytes
Concurrency Level:      10
Time taken for tests:   1.795 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      996700 bytes
HTML transferred:       979700 bytes
Requests per second:    55.72 [#/sec] (mean)
Time per request:       179.478 [ms] (mean)
Time per request:       17.948 [ms] (mean, across all concurrent requests)
Transfer rate:          542.32 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3  11.0      0      56
Processing:    74  171  82.2    155     642
Waiting:       68  150  81.1    133     628
Total:         74  175  83.4    157     644
Percentage of the requests served within a certain time (ms)
  50%    157
  66%    176
  75%    191
  80%    196
  90%    210
  95%    232
  98%    642
  99%    644
 100%    644 (longest request)

Textpattern 4.6-dev:

bert@jessie:~$ ab -n 100 -c 10 http://jessie/textpattern-dev/
Document Path:          /textpattern-dev/
Document Length:        9823 bytes
Concurrency Level:      10
Time taken for tests:   3.506 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      999300 bytes
HTML transferred:       982300 bytes
Requests per second:    28.52 [#/sec] (mean)
Time per request:       350.575 [ms] (mean)
Time per request:       35.058 [ms] (mean, across all concurrent requests)
Transfer rate:          278.36 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3  11.3      0      62
Processing:   198  333 124.8    299     930
Waiting:      183  296 121.2    261     870
Total:        198  336 128.3    299     930
Percentage of the requests served within a certain time (ms)
  50%    299
  66%    322
  75%    346
  80%    359
  90%    445
  95%    605
  98%    904
  99%    930
 100%    930 (longest request)

bert@jessie:~$

Last edited by hcgtv (2015-06-24 14:01:30)

Offline

#99 2015-06-24 14:07:43

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

Re: Making plugins first-class citizens

hcgtv wrote #291962:

I can confirm your findings.

Yowzers. A 50% performance drop is waaaay worse than I’d hoped.

My best guess as to the root cause is still just that: a guess. If there are bottlenecks introduced with all the OO overhead (or somewhere else in the system) I’d like to find out exactly where and improve those parts through optimisation or judicial cacheing.

Anyone got any techniques for identifying where 4.6.-dev is spending most of its time?


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

#100 2015-06-24 18:08:34

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,721
Website

Re: Making plugins first-class citizens

Went back to tinkering after a big lunch (rice, fried eggs, fried plantains), looked at what was different between the Textpattern 4.5.7 install and the Textpattern 4.6-dev install. Aside from the fact that each install had my templates plugin activated, on the 4.6-dev site, I had the ied_plugin_composer plugin installed and activated also. Never thought an admin side plugin could affect front page speed.

Here are the new tests, sites set to Live, no plugins activated.

Textpattern 4.5.7

bert@jessie:~$ ab -n 100 -c 10 http://jessie/zendstudio/textpattern/
Document Path:          /zendstudio/textpattern/
Document Length:        10017 bytes
Concurrency Level:      10
Time taken for tests:   1.743 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1025800 bytes
HTML transferred:       1001700 bytes
Requests per second:    57.36 [#/sec] (mean)
Time per request:       174.322 [ms] (mean)
Time per request:       17.432 [ms] (mean, across all concurrent requests)
Transfer rate:          574.66 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4  14.8      0      71
Processing:    90  165  71.4    153     777
Waiting:       74  143  71.8    133     774
Total:         90  169  73.1    158     777
Percentage of the requests served within a certain time (ms)
  50%    158
  66%    181
  75%    189
  80%    192
  90%    208
  95%    223
  98%    331
  99%    777
 100%    777 (longest request)

Textpattern 4.6-dev

bert@jessie:~$ ab -n 100 -c 10 http://jessie/zendstudio/textpattern-dev/
Document Path:          /zendstudio/textpattern-dev/
Document Length:        10083 bytes
Concurrency Level:      10
Time taken for tests:   2.088 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1032400 bytes
HTML transferred:       1008300 bytes
Requests per second:    47.90 [#/sec] (mean)
Time per request:       208.781 [ms] (mean)
Time per request:       20.878 [ms] (mean, across all concurrent requests)
Transfer rate:          482.90 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3  11.7      0      62
Processing:   106  200  89.5    189     825
Waiting:       88  174  90.4    163     794
Total:        106  204  89.9    193     825
Percentage of the requests served within a certain time (ms)
  50%    193
  66%    202
  75%    214
  80%    220
  90%    231
  95%    268
  98%    605
  99%    825
 100%    825 (longest request)

ZendStudio arrived today :)

Offline

#101 2015-06-24 18:16:01

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

Re: Making plugins first-class citizens

hcgtv wrote #291998:

Never thought an admin side plugin could affect front page speed.

I added a few tags to allow you to output info from installed plugins on your site. Guess I ballsed it up somewhere along the line. Thanks for finding the bottleneck, I’ll go and check out why. Found another bug in the admin-side prefs saving routine today anyway so it need attention.

Those results are a whole lot better and more in line with what I expected. Phew! Still going to look into optimisations at some point though. Thanks for testing.


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

#102 2015-06-25 01:30:45

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,721
Website

Re: Making plugins first-class citizens

Spent the day setting up Zend Studio 12.5 on my Windows 7 box. When getting remote debugging working, I turned off the OpCache that PHP 5.6 turns on by default in Debian Jessie. Ran the benchmarks over again, what a difference the cache makes.

Here are the new tests, sites set to Live, no plugins activated.

Textpattern 4.5.7

bert@jessie:~$ ab -n 100 -c 10 http://jessie/zendstudio/textpattern/
Document Path:          /zendstudio/textpattern/
Document Length:        10017 bytes
Concurrency Level:      10
Time taken for tests:   5.882 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1031300 bytes
HTML transferred:       1001700 bytes
Requests per second:    17.00 [#/sec] (mean)
Time per request:       588.228 [ms] (mean)
Time per request:       58.823 [ms] (mean, across all concurrent requests)
Transfer rate:          171.21 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3  10.8      0      57
Processing:   267  575 276.6    502    1709
Waiting:      260  536 272.8    466    1667
Total:        267  578 275.9    504    1709
Percentage of the requests served within a certain time (ms)
  50%    504
  66%    531
  75%    549
  80%    559
  90%    659
  95%   1359
  98%   1707
  99%   1709
 100%   1709 (longest request)

Textpattern 4.6-dev

bert@jessie:~$ ab -n 100 -c 10 http://jessie/zendstudio/textpattern-dev/
Document Path:          /zendstudio/textpattern-dev/
Document Length:        10083 bytes
Concurrency Level:      10
Time taken for tests:   6.939 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1037900 bytes
HTML transferred:       1008300 bytes
Requests per second:    14.41 [#/sec] (mean)
Time per request:       693.896 [ms] (mean)
Time per request:       69.390 [ms] (mean, across all concurrent requests)
Transfer rate:          146.07 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3   9.3      0      44
Processing:   348  680 242.9    621    1705
Waiting:      336  633 238.4    567    1651
Total:        348  682 242.5    622    1705
Percentage of the requests served within a certain time (ms)
  50%    622
  66%    640
  75%    676
  80%    698
  90%    769
  95%   1413
  98%   1693
  99%   1705
 100%   1705 (longest request)

Zend Studio reports 2,375 warnings from the Textpattern 4.5.7 directory tree. Debugging is working great, incredible interface on this Eclipse based IDE from Zend. Now to set breakpoints, step through the code, get acquainted with the dev branch.

bert@jessie:~$

Offline

#103 2015-06-25 09:12:43

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,721
Website

Re: Making plugins first-class citizens

Latest results, increased the RAM to 3GB in VirtualBox.

Debian GNU/Linux 8.1 "jessie" - Apache 2.4.10 - MySQL 5.5.43 - PHP 5.6.9 - VM RAM 3GB

Textpattern 4.5.7

bert@jessie:~$ ab -n 100 -c 10 http://jessie/zendstudio/textpattern/
Document Length:        10017 bytes
Concurrency Level:      10
Time taken for tests:   4.867 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1031300 bytes
HTML transferred:       1001700 bytes
Requests per second:    20.55 [#/sec] (mean)
Time per request:       486.675 [ms] (mean)
Time per request:       48.668 [ms] (mean, across all concurrent requests)
Transfer rate:          206.94 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4  13.2      0      68
Processing:   298  460 150.6    420    1160
Waiting:      277  435 150.6    391    1141
Total:        298  464 151.6    422    1160
Percentage of the requests served within a certain time (ms)
  50%    422
  66%    449
  75%    459
  80%    467
  90%    597
  95%    712
  98%   1146
  99%   1160
 100%   1160 (longest request)

Zend OPcache

Document Length:        10017 bytes
Concurrency Level:      10
Time taken for tests:   1.696 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1031300 bytes
HTML transferred:       1001700 bytes
Requests per second:    58.98 [#/sec] (mean)
Time per request:       169.554 [ms] (mean)
Time per request:       16.955 [ms] (mean, across all concurrent requests)
Transfer rate:          593.99 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5  15.4      0      72
Processing:    87  161  60.8    150     663
Waiting:       81  146  60.5    134     650
Total:         87  166  62.6    157     663
Percentage of the requests served within a certain time (ms)
  50%    157
  66%    177
  75%    186
  80%    189
  90%    219
  95%    231
  98%    280
  99%    663
 100%    663 (longest request)

Textpattern 4.6-dev

bert@jessie:~$ ab -n 100 -c 10 http://jessie/zendstudio/textpattern-dev/
Document Length:        12159 bytes
Concurrency Level:      10
Time taken for tests:   5.074 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1238400 bytes
HTML transferred:       1215900 bytes
Requests per second:    19.71 [#/sec] (mean)
Time per request:       507.447 [ms] (mean)
Time per request:       50.745 [ms] (mean, across all concurrent requests)
Transfer rate:          238.33 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   2.2      0      11
Processing:   255  489 159.6    461    1549
Waiting:      246  458 156.9    427    1509
Total:        255  489 160.6    461    1559
Percentage of the requests served within a certain time (ms)
  50%    461
  66%    469
  75%    478
  80%    485
  90%    588
  95%    616
  98%   1106
  99%   1559
 100%   1559 (longest request)

Zend OPcache

Document Length:        12158 bytes
Concurrency Level:      10
Time taken for tests:   1.727 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1238300 bytes
HTML transferred:       1215800 bytes
Requests per second:    57.90 [#/sec] (mean)
Time per request:       172.718 [ms] (mean)
Time per request:       17.272 [ms] (mean, across all concurrent requests)
Transfer rate:          700.14 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3   9.7      0      50
Processing:   101  167  46.6    163     561
Waiting:       84  147  45.2    145     530
Total:        101  170  49.2    163     561
Percentage of the requests served within a certain time (ms)
  50%    163
  66%    175
  75%    180
  80%    185
  90%    200
  95%    232
  98%    296
  99%    561
 100%    561 (longest request)

The Results:

bert@jessie:~$ ab -n 100 -c 10		OPcache on		OPcache off
Textpattern 4.5.7			1.696 seconds		4.867 seconds
Textpattern 4.6-dev			1.727 seconds		5.074 seconds

The tests were run multiple times, giving the Apache server ample time to cache the PHP opcode.

bert@jessie:~$

Offline

#104 2015-06-25 09:24:46

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

Re: Making plugins first-class citizens

So the OPcache gives us roughly a 3-fold increase in raw rendering speed. Nice. And the difference between 4.5.7 and 4.6-dev isn’t as pronounced as I’d feared yesterday under such conditions. That’s encouraging, though anywhere we can inject some speed enhancements will be a boon.

If we can run the Pages/Forms/Styles out of the filesystem that will probably help as it’ll cut down on DB access. Coupled with the parser tweaks that Ruud and etc have made (when — not if — they land in core) I think we’re onto a winner. Thanks, Bert.

[Edited to remove stupid closing comment after realising the tests were for 100 iterations]

Last edited by Bloke (2015-06-25 09:27:33)


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

#105 2015-06-25 15:55:05

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,721
Website

Re: Making plugins first-class citizens

Bloke wrote #292046:

So the OPcache gives us roughly a 3-fold increase in raw rendering speed. Nice. And the difference between 4.5.7 and 4.6-dev isn’t as pronounced as I’d feared yesterday under such conditions. That’s encouraging, though anywhere we can inject some speed enhancements will be a boon.

What I did was to install a fresh copy of 4.6-dev, then ran the tests, I didn’t want plugins affecting the outcome. Take into account that any calls the default template makes to external sources, for fonts or scripts adds to the overhead.

If we can run the Pages/Forms/Styles out of the filesystem that will probably help as it’ll cut down on DB access. Coupled with the parser tweaks that Ruud and etc have made (when — not if — they land in core) I think we’re onto a winner.

I don’t mind the Pages/Forms/Styles in the database. I remember running tests when Ruud was playing round with having the Styles called from the file system, versus the database calls in css.php and all that. From my tests, the database calls beat out the file system calls (ApacheBench). There’s a forum thread somewhere?

Offline

#106 2015-06-25 22:33:27

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

Re: Making plugins first-class citizens

hcgtv wrote #292074:

I remember running tests when Ruud was playing round with having the Styles called from the file system, versus the database calls in css.php and all that. From my tests, the database calls beat out the file system calls (ApacheBench). There’s a forum thread somewhere?

Same style sheet, ab -n 100 -c 10, admittedly by performing the test from the server itself, to avoid the 100ms latency between me and the server from influencing the results.:
<txp:rvm_css>: 4000 requests/sec
<txp:css>: 50 requests/sec

You won’t get similar results by putting forms/pages on the filesystem, because those would still be called from within a PHP script, while <txp:rvm_css> results in a request for a static file by the browser.

Offline

#107 2015-06-25 23:42:07

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

Re: Making plugins first-class citizens

ruud wrote #292093:

You won’t get similar results by putting forms/pages on the filesystem, because those would still be called from within a PHP script

I’ve been mulling this over the last few days, and agree. The filesystem is fine for storage and cacheing, but it brings its own demons:

  • A different security model to the rest of the data. OK, it’s not necessarily customer or client data, more configuration, but it’s still different.
  • It follows from the above that different hosts require different permission structures. We all know of the hosts who tell people to set their folders to 777. What permissions should Txp use, and what issues do we hit / have to code around if we can’t save a template for some reason?
  • DBs can optimise and cache accesses and content automatically, especially when the data size is small like Pages and Forms tend to be. File systems usually need help in the form of external solutions like memcached. So unless you happen to be running such a solution, Filesystem + no cache might feel slower than DB + its own cache (even though DBs ultimately use the filesystem to store their indexes and data for persistence).
  • Concurrent access to files is patchy across OSs. Databases queue requests and process them automatically when locking / other threads have completed. Files often just balk if they’re in use by someone else, or trash data.
  • If you’re accessing a Page + 10 Forms + 2 Stylesheets from the same spinning platter filesystem in a relatively short time frame, the disk head is going to thrash as it competes for resources. A DB wouldn’t necessarily do that if it had cached some or all of the data (although we’re using TEXT column types which don’t get cached in memory anyway). SSDs help here of course, but they’re not widespread in hosting environments yet.

I’m sure there are other factors. In fact, the only true benefit to using the filesystem seems to be for taking advantage of VCS. That is a big draw in its favour.

We could fairly easily disambiguate the whole “which one is master” thing by adding a last_modified column to each table. If, when you visit the Pages panel, the file timestamp is newer, that’s loaded into the textarea. Otherwise, the DB content is loaded. That still leaves some window of opportunity for them to drift out of sync (if you don’t visit the admin side after changing a file, for example) so we’d need to find some way to sync things on other events, or signal somehow (like I believe rah_flat does?)

The only other worries are praying that the whole shebang doesn’t fall apart at DST switchover times, and choosing which system is used by the core tags. Retaining the DB as master with file system as backup is less work, but doesn’t really deliver any hardcore benefits compared with going to the trouble of implementing it. Employing the vice versa, or ditching the DB entirely, are both a backwards compatibility/plugin minefield unless we’re clever about it. Oh the dilemma…


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

#108 2015-06-26 08:52:07

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

Re: Making plugins first-class citizens

Bloke wrote #292098:

It follows from the above that different hosts require different permission structures. We all know of the hosts who tell people to set their folders to 777. What permissions should Txp use, and what issues do we hit / have to code around if we can’t save a template for some reason?

During the install, test if the uploaded TXP files are owned by a different user than the process running PHP scripts. If so, abort the install and recommend the user to switch to a more secure host. The bonus is that TXP doesn’t get blamed for security issues when the real cause is the way the host is set up.

DBs can optimise and cache accesses and content automatically, especially when the data size is small like Pages and Forms tend to be. File systems usually need help in the form of external solutions like memcached. So unless you happen to be running such a solution, Filesystem + no cache might feel slower than DB + its own cache.

Not sure about Windows, but Linux caches files in RAM (if you have enough).

Concurrent access to files is patchy across OSs. Databases queue requests and process them automatically when locking / other threads have completed. Files often just balk if they’re in use by someone else, or trash data.

Not a problem for reading files. Might be a problem if you update a template, but since templates are typically small, uploading takes a very short time so it won’t affect many users visiting the website.

SSDs help here of course, but they’re not widespread in hosting environments yet.

They are, actually. Pick a decent host :)

The only other worries are praying that the whole shebang doesn’t fall apart at DST switchover times

IMHO, servers should use UTC or at least a timezone setting which isn’t affected by DST. You don’t want DST messing up logfiles.

Having said that. I like the fact that we have forms/templates in the DB. Storing them as flat files feels old-fashioned.

Offline

Board footer

Powered by FluxBB