Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: rvm_css (v1.2)
I’m not sure if I’m on the right tack here Steve but I think it depends on where you are within the “system” for example in my xamplite install I need to use C:\xampplite\htdocs\designer\files and something similar for the temp file path (also the path to textpattern in the config.php file) however all other links ie navigation etc are “/” which may be because they are within the PHP environment?? Anyway I have no problems with plug-ins.
Last edited by thebombsite (2008-01-03 16:31:55)
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
#26 2008-01-03 16:48:38
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: rvm_css (v1.2)
Stuart
A little confusing. I’ll try to explain it…
URLs such as the navigation links will be ‘/’ as that’s what the URL spec says they need to be. However, file-path delimiters are different and controlled by the OS writers with no universal standard. On *nix the ‘/’ character is used and on Windows the ‘\’ character is the one used.
If I understand correctly, Wet was pointing out that whilst you can say to Windows “go to C:\My Documents” or “go to C:/My Documents” it will do so but when you ask “Where am I?” it will then say “C:\My Documents” — using the ‘\’ character.
Result, plugin writers who want cross-OS compatible plugins that deal with file-paths need to be careful to compare against the correct OS specific path delimiter when they get paths from the OS. That can easily be taken care of by using the DS definition instead of hard-coding ‘/’ or ‘\’ characters into the plugin.
Last edited by net-carver (2008-01-03 16:51:14)
— Steve
Offline
Re: rvm_css (v1.2)
Got it. :)
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
#28 2008-01-03 22:55:39
- nardo
- Member
- From: tuvalahiti
- Registered: 2004-04-22
- Posts: 743
Re: rvm_css (v1.2)
net-carver – not sure if this is relevant; but can confirm ruud’s plugin working on IIS server – and working great!!
Offline
Re: rvm_css (v1.2)
Ruud,
Just got a chance to try this out on a new site running r2762.
Decided to run Apache Bench: ab -c 5 -n 100 http://mysite.com
Without the plugin:
Concurrency Level: 5
Time taken for tests: 2.903062 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 326500 bytes
HTML transferred: 301600 bytes
Requests per second: 34.45 1 (mean)
Time per request: 145.153 [ms] (mean)
Time per request: 29.031 [ms] (mean, across all concurrent requests)
Transfer rate: 109.54 [Kbytes/sec] received
With the plugin:
Concurrency Level: 5
Time taken for tests: 3.412726 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 325800 bytes
HTML transferred: 300900 bytes
Requests per second: 29.30 1 (mean)
Time per request: 170.636 [ms] (mean)
Time per request: 34.127 [ms] (mean, across all concurrent requests)
Transfer rate: 93.18 [Kbytes/sec] received
- Apache 2.2.6 – HTTP server
- MySQL 5.0.51 – Database server
- PHP 5.2.4 – Web scripting language
- APC 3.0.16 – Alternative PHP Cache
This particular server is running the APC (opcode cache), since css.php is already cached, could having to go out to disk to retrieve the css file be slowing it down?
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: rvm_css (v1.2)
Bert, try benchmarking the difference between loading css.php and the static stylesheet.css file instead. When using ‘ab’ as you are, it only benchmarks the loading of the main website HTML code, but not the loading of the style sheet.
For the main website, the difference for the normal website page in execution speed should be at most: 1 SQL query (retrieving the stylesheet name from the DB is not a complex query so it should be fast) and 1 filesystem call to check if the stylesheet file is present and can be read (the result should be cached by the filesystem).
When using an opcode cache I’m guessing the difference between css.php and a static style sheet is less, but the static file should still be a lot faster if you have enough RAM to cache, because then it will be cached by the OS in RAM.
Hmm… I’m wondering if you’d get a speed increase by putting the plugin code in the plugin_cache directory, because then APC can cache it. If it has to be loaded from the database and then eval-ed, I suspect APC can’t cache it. This is only the loading of the plugin I’m talking about here, btw, not the actual use of the plugin.
Offline
Re: rvm_css (v1.2)
ruud wrote:
Bert, try benchmarking the difference between loading css.php and the static stylesheet.css file instead.
Let’s welcome JoeDog’s siege to the proceedings.
urls-cssphp.txt:
http://txpage.com/about/
http://txpage.com/textpattern/css.php?s=about
http://txpage.com/textpattern/txp_img/carver.gif
http://txpage.com/images/1.gif
siege -d1 -r10 -c25 -f /home/bert/urls-cssphp.txt
Transactions: 250 hits
Availability: 100.00 %
Elapsed time: 7.22 secs
Data transferred: 0.48 MB
Response time: 0.08 secs
Transaction rate: 34.63 trans/sec
Throughput: 0.07 MB/sec
Concurrency: 2.84
Successful transactions: 250
Failed transactions: 0
Longest transaction: 0.92
Shortest transaction: 0.00
urls-static.txt:
http://txpage.com/about/
http://txpage.com/_templates/default.css
http://txpage.com/textpattern/txp_img/carver.gif
http://txpage.com/images/1.gif
siege -d1 -r10 -c25 -f /home/bert/urls-static.txt
Transactions: 250 hits
Availability: 100.00 %
Elapsed time: 7.86 secs
Data transferred: 0.48 MB
Response time: 0.02 secs
Transaction rate: 31.81 trans/sec
Throughput: 0.06 MB/sec
Concurrency: 0.75
Successful transactions: 250
Failed transactions: 0
Longest transaction: 0.19
Shortest transaction: 0.00
The APC cached css.php wins against the static css file, go figure.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: rvm_css (v1.2)
I did the same thing but compared as rudd suggested:
My css file is 28k big.
Without:
Concurrency Level: 5
Time taken for tests: 12.173134 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2894400 bytes
HTML transferred: 2880400 bytes
Requests per second: 8.21 1 (mean)
Time per request: 608.657 [ms] (mean)
Time per request: 121.731 [ms] (mean, across all concurrent requests)
Transfer rate: 232.15 [Kbytes/sec] received
With:
Concurrency Level: 5
Time taken for tests: 2.338252 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2904100 bytes
HTML transferred: 2880400 bytes
Requests per second: 42.77 1 (mean)
Time per request: 116.913 [ms] (mean)
Time per request: 23.383 [ms] (mean, across all concurrent requests)
Transfer rate: 1212.87 [Kbytes/sec] received
This plugin is awesome! What else might be speeded up using this method? Would it make sense to have static pages and forms as well?
Last edited by typeshige (2008-01-06 18:13:39)
Offline
Re: rvm_css (v1.2)
This is what I get, with a CSS file that’s 2.4kB
without: ab -c 5 -n 250 http://path/to/css.php
Requests per second: 10.46 1 (mean)
with: ab -c 5 -n 10000 http://path/to/static.css
Requests per second: 1026.68 1 (mean)
I used 10000 on the second one so the tests ran an near equal amount of time (otherwise the second test would be too inaccurate). This was tested by using “ab” on the same server that hosted the website to exclude network latencies and throughput issues.
Bert, I think you’re not measuring APC speed, but some kind of connection limitation on the webserver that hosts your website or simply the latency or throughput fluctuation between your webhost and the server where you’re running “ab” or “siege”.
typeshige, you can’t use this to speed up forms/pages in TXP, because those are combined with article data that is pulled from the database to form the website page that is sent to the visitor. The technique to speed up css files here really only works for page elements (as requested by the browser!) that can be stored entirely as a static file.
Offline
Re: rvm_css (v1.2)
ruud wrote:
Bert, I think you’re not measuring APC speed, but some kind of connection limitation on the webserver that hosts your website or simply the latency or throughput fluctuation between your webhost and the server where you’re running “ab” or “siege”.
The tests were run on the same machine that runs the websites.
All I know is that with APC, the amount of requests my web server can handle was multiplied by a factor of 5. Which I think is what brings a site using css.php on par with a statically linked css file, at least that’s what all my tests have shown.
On a side note, the way you save off the CSS to a file could be extended to pages and forms. If you don’t mind, may I use some of your logic and add it to my templates plugin? I want to make the directory where the templates are stored an admin preference and I’d like to have archive capabilities with timestamped files, for backup purposes.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: rvm_css (v1.2)
Bert, my plugins are released under GPLv2 or later license. Within the limits of that license, you’re free to re-use my code ;)
Offline
Re: rvm_css (v1.2)
hcgtv wrote:
On a side note, the way you save off the CSS to a file could be extended to pages and forms. If you don’t mind, may I use some of your logic and add it to my templates plugin? I want to make the directory where the templates are stored an admin preference and I’d like to have archive capabilities with timestamped files, for backup purposes.
do you mean we could have ‘revisions’ of say..a css stylesheet?
for example in typolight CMS, whenever you save a stylesheet, a revision is made so you can easily revert a change:
Last edited by iblastoff (2008-01-06 23:43:01)
Offline