Textpattern CMS support forum

You are not logged in. Register | Login | Help

#111 2015-06-26 16:50:38

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

Re: Making plugins first-class citizens

This has been an interesting exercise, if nothing else to help me tweak Debian “Jessie” running in VirtualBox.

My previous development VM was a Debian “Lenny” 32bit install, later upgraded to “Wheezy”. This 80GB VDI, was assigned 1 CPU and 2GB of ram. When I installed “Jessie” in a new 100GB VDI, I opted for the 64bit version. So while I’ve been benchmarking Textpattern, I’ve also been tweaking the virtual machine.

Tweaking memory has it’s benefits to a certain degree, for my setup, “Jessie” with the Gnome 3 desktop, 2GB of ram feels about right. I have a total of 8GB of ram on my desktop, this leaves me plenty of ram to run the programs I need on the Windows 7 host side. Assigning 3GB of ram to the VM saw no real improvement in times, whether from Apache running a PHP app or my Perl script that generates the cross references over at PHPCrossref.com.

The one option I’ve never played with was the number of CPUs, so I decided to give the VM access to both the CPUs on the machine’s Intel E5700 Dual Core, running at 3.0GHz. Not a scorcher of a machine, but I’m not rendering Jurassic World, just doing 2D text wrangling. What a surprise I was met with, the 64bit linux operating system took to the dual CPUs like it was made for them. Brought my BogoMIPS up to 11,971, highest number I’ve ever achieved.

So here are the new tests – 2 CPUs, 2GB of RAM, PHP OPcache is off (not conducive to dev work):

Textpattern 4.5.7

Document Length:        9983 bytes
Concurrency Level:      10
Time taken for tests:   2.846 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1027900 bytes
HTML transferred:       998300 bytes
Requests per second:    35.13 [#/sec] (mean)
Time per request:       284.624 [ms] (mean)
Time per request:       28.462 [ms] (mean, across all concurrent requests)
Transfer rate:          352.68 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   7.3      0      33
Processing:   120  277  91.2    270     814
Waiting:      118  260  88.1    256     769
Total:        121  279  92.0    270     814
Percentage of the requests served within a certain time (ms)
  50%    270
  66%    286
  75%    300
  80%    306
  90%    329
  95%    389
  98%    677
  99%    814
 100%    814 (longest request)

Textpattern 4.6-dev

Document Length:        12157 bytes
Concurrency Level:      10
Time taken for tests:   3.138 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1238200 bytes
HTML transferred:       1215700 bytes
Requests per second:    31.86 [#/sec] (mean)
Time per request:       313.834 [ms] (mean)
Time per request:       31.383 [ms] (mean, across all concurrent requests)
Transfer rate:          385.29 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   6.2      0      27
Processing:   126  304  79.9    293     706
Waiting:      124  286  78.1    271     691
Total:        126  306  81.2    293     706
Percentage of the requests served within a certain time (ms)
  50%    293
  66%    314
  75%    321
  80%    331
  90%    355
  95%    401
  98%    676
  99%    706
 100%    706 (longest request)

After years of playing around with VirtualBox, my current setup has all the VDI files on a separate partition. This partition has been added to the Avast! exclusions, no need to waste precious disk reads on checking for viruses in Linux.

Next month, I plan on getting a 240GB SSD drive to run Windows 10. 240GB is plenty of room for Windows 10 and the 100GB Debian “Jessie” VDI disk file. This should increase my VM performance quite substantially, and I get to leave my Windows 7 install intact while I transition over to Windows 10.

My Lenovo desktop specs, if anyone is interested.

Offline

#112 2015-06-26 22:05:55

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

Re: Making plugins first-class citizens

100GB? You can probably lose a zero.

Offline

#113 2015-06-26 22:19:42

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

Re: Making plugins first-class citizens

ruud wrote #292153:

100GB? You can probably lose a zero.

A Debian 8.1 install with Gnome 3 as the default desktop is 3.7GB, so yes, 10GB is all you really need to setup a quick desktop/lamp server.

My need for 100GB is that I use my VM to work on PHPCrossRef. The cross reference dev environment occupies upwards of 50GB at the moment, and I plan on adding more projects. It’s pretty cool to use sed or perl on the huge source tree and look for stuff.

Shopping for an SSD now, can’t wait to compare the speed.

Offline

#114 2017-12-06 16:00:18

etc
Developer
Registered: 2010-11-11
Posts: 3,157
Website

Re: Making plugins first-class citizens

Just a poll: short tags are there since 4.6. Is anybody using them?


etc_[ query | search | pagination | date | tree | cache ]

Offline

#115 2017-12-06 16:01:33

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

Re: Making plugins first-class citizens

/me raises hand.


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

#116 2017-12-06 16:03:36

etc
Developer
Registered: 2010-11-11
Posts: 3,157
Website

Re: Making plugins first-class citizens

Stef, I know for you :-)


etc_[ query | search | pagination | date | tree | cache ]

Offline

#117 2017-12-06 16:09:27

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,237
Website

Re: Making plugins first-class citizens

etc wrote #308129:

Just a poll: short tags are there since 4.6. Is anybody using them?

not yet:(


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | Respbublika! | NeMe @ github

Offline

#118 2017-12-06 16:24:43

etc
Developer
Registered: 2010-11-11
Posts: 3,157
Website

Re: Making plugins first-class citizens

Okay, since we’ve got a user, we can not revert it back, but could make it optional (on/off pref). There are at least two reasons you might want to switch it off:

  • your content/code contains <some::patterns /> that must not be processed by Textpattern;
  • you gain ~5% speed in long loops (e.g. large article lists).

Is it worth introducing a pref? The downside is that switching short tags off will break your (or others) code if it contains them.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#119 2017-12-06 16:51:42

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

Re: Making plugins first-class citizens

I’m only using it on my dev site. So don’t worry about backwards compat if it’s only me.

I agree it’s nice to be able to switch it off if there are any XML paths that might clash or (potentially) slow down your site as the entire XML tree is passed through the Txp parser.

Unless there could be some other way to shield portions of your code from the parser? <txp:hide> would have been a candidate, but now we can use that to do internal processing(?), I guess that’s not an option any more.


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

#120 2017-12-06 20:19:31

etc
Developer
Registered: 2010-11-11
Posts: 3,157
Website

Re: Making plugins first-class citizens

Bloke wrote #308134:

Unless there could be some other way to shield portions of your code from the parser? <txp:hide> would have been a candidate, but now we can use that to do internal processing(?), I guess that’s not an option any more.

Interesting idea. We can modify <txp:hide /> so that <txp:hide process="">thing</txp:hide> will finally (after secondpass) output the unprocessed thing. Though thing will still be parsed (without processing), this happens only once, so there should be no noticeable slowdown. Will commit after some testing.

But this does not protect against copy-pasting others code with <short::tags /> and forgetting to enable them. Caveat utilitor?


etc_[ query | search | pagination | date | tree | cache ]

Offline

Board footer

Powered by FluxBB