Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
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.9Textpattern 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)
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
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
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 :)
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#101 2015-06-24 18:16:01
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
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:~$
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#103 2015-06-25 09:12:43
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 3GBTextpattern 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 secondsThe tests were run multiple times, giving the Apache server ample time to cache the PHP opcode.
bert@jessie:~$
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#104 2015-06-25 09:24:46
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
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?
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#106 2015-06-25 22:33:27
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
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
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