Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

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

Online

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

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,634
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,634
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: 8,841
Website

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

Online

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

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,634
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: 8,841
Website

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

Online

#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

#109 2015-06-26 09:10:31

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

Re: Making plugins first-class citizens

ruud wrote #292118:

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.

I like that! Nice and simple. Good idea.

[SSDs] are, actually. Pick a decent host :)

OK, my fault, sorry. I should have checked.

IMHO, servers should use UTC or at least a timezone setting which isn’t affected by DST.

Amen. All this safe_strftime(), timezone and DST conversion junk is noise I could do without.

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

I like them in the DB too. If it weren’t for the VCS thing, I’d agree completely. It’d just be nice to have a way to fairly seamlessly manage them externally under version control as well if that suits your workflow, and make it less nebulous what’s going to happen to your site when you make changes. Might be onto something here. Not sure yet, needs a little thought and refining.


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

Online

#110 2015-06-26 14:13:19

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

Re: Making plugins first-class citizens

ruud wrote #292093:

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

Ah yes I remember, <txp:rvm_css> – tried to test v1.0 on 4.5.7, getting no output from the tag on the default page.

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.

On my local VM, using Textpattern 4.5.7, I get the same times whether I use <txp:css format="link" media="" /> or <link rel="stylesheet" href="<txp:site_url />themes/default.css">. Apache bench reports between 4.9 and 5.1 seconds to complete ab -n 100 -c 10.

Did we say more tests!

My dynamic sites are on a shiny new VPS at DreamHost, 2000MB of RAM, 60GB of SSD disk space.
PHP 5.4.36 with XCache enabled on all domains.

Textpattern 4.4.1e – default template, only plugin installed is hcg_templates:

[ps######]$ ab -n 100 -c 10 http://nupusi.com/
Document Length:        3150 bytes
Concurrency Level:      10
Time taken for tests:   0.694 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      330400 bytes
HTML transferred:       315000 bytes
Requests per second:    144.13 [#/sec] (mean)
Time per request:       69.380 [ms] (mean)
Time per request:       6.938 [ms] (mean, across all concurrent requests)
Transfer rate:          465.05 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       3
Processing:    26   66  11.3     66      82
Waiting:       25   66  11.4     66      82
Total:         29   66  11.0     66      84
Percentage of the requests served within a certain time (ms)
  50%     66
  66%     71
  75%     74
  80%     77
  90%     80
  95%     82
  98%     82
  99%     84
 100%     84 (longest request)

“Even though you are on the right track – you will get run over if you just sit there.”
Will Rogers

Offline

Board footer

Powered by FluxBB